[Types-sig] Interface files

[Martijn Faassen]

Paul Prescod wrote:
> 
> Greg Stein wrote:
> >
> > I stated a preference for allowing this information to reside in the same
> > file as the implementation. i.e. I don't want to maintain two files.
> 
> The nice thing about having separate files is that it becomes instantly
> clear what is "interesting" to the compiler. We have no backwards
> compatibility constraints. We have no questions about what variable are
> "in scope" and "available". It's just plain simpler.

Look at my proposal (response to Guido's challenge). It's in the same
file, and backwardly compatible, and it's instantly clear what the
compiler looks at.

> There is also something deeply elegant and useful about a separation of
> interface from implementation.

It can be helpful, but that doesn't mean it needs to be in a separate
file. :)

> Sure, you don't always want to be REQUIRED to separate them. I
> acknowledge that we will one day have to support inline declarations but
> I'm going to put it off unless I hear some screaming.

Right, but Greg can't put it off, as he is advocating his operators,
which have to be inline.

> > I'll go further and state that we should not use a new language for this.
> > It should just be Python. (and this is where Martijn's __types__ thing
> > comes in, although I'm not advocating that format)
> 
> I think that that's an unreasonable (and unreadable) constraint. The
> language should probably be pythonic, but not necessarily Python. Python
> doesn't have a type declaration syntax and none of Python's existing
> syntax was meant to be used AS a type declaration syntax. It just gets
> too unreadable for quasi-complicated declarations. We need to support
> polymorphic and parameteric higher order functions!

It may become fairly readable if you support typedefs (which can be used
in type anontations). But I agree that this isn't the final solution;
the final solution should probably be some nice Pythonic syntax. But for
now:

* it's quickly implementable

* it's instantly usable by tools written in Python

* it's understandable by anyone who can read Python

* it's backwards compatible

* we don't have to debate about syntax anymore and can actually think
about
  semantics without syntax confusion.

These are major advantages during the development.

Regards,

Martijn