[Types-sig] Shadow File Opinions?

[Greg Stein]

On Tue, 14 Dec 1999, Paul Prescod wrote:
> Martijn Faassen wrote:
> > 
> > ...
> > While my agenda is to kill the syntax discussions for the moment, I'd
> > propose a seperate declaration syntax before all others, because this is
> > the most syntactically compatible with Python. And easier on the
> > programmer.
> 
> I'm considering your argument carefully. If we make separate interface
> files then we get Python 1.5 (hell, Python 1.0) compatibility "for free"
> and we can experiment with different syntaxes without breaking Python
> code. Plus we could use IDL and type libraries for type analysis
> *already*.
> 
> I think the final product must allow inline declarations but I am
> starting to think that in the short term, "interface definition" files
> are the way to go not just for builtin modules but for all modules.
> 
> Do others agree?

Interface files and/or Martijn's approach. Personally, I like Martijn's a
bit better because you don't have to juggle two files.

But yes: it solves a short-term problem of "what is the syntax for
defining a module/class interface (its func and attr signatures)".

Although I think func signatures are an easy syntactic extension which
several people have provided samples for, so the interface can use that.
The attributes of a module/class are the hard part. And no... I haven't
read JimF's proposal yet to see his suggestion for how this might be 
done... it does apply to this problem. And here we tried to separate
interfaces from the discussion :-)

Suggestion: defer consideration of interfaces (whether via Martijn's
approach or a separate file) for V2 of the type system design. For V1,
let's concentrate on applying type signatures to functions (and variables
if people insist :-), and any type inferencing that may be needed.

I believe there are a lot of associated problems to handle before needing
to throw the interface problem into the mix. Seriously, I only see
interfaces as providing a way to define type info for attributes (within
the context of this discussion; they have other uses). We have issues
dealing with the existing modules, backwards/forwards compatibility, what
constitutes type-safety, what checks are available, what runtime switches
are used, etc.
[ many of these types of details goes into the RFC Paul is putting
  together ]

>...
> > With either a Python based system as I'm proposing (ugly but powerful
> > and fairly simple), or a seperate type declaration system, you have your
> > type declarations separated from the code itself. This means you easily
> > add and remove type information and switch between a statically typed
> > module and a dynamically typed module easily.
> 
> But there is not going to be alot of "switching". You add declarations
> and you leave them there. You update them when they get out of sync with
> the code. Why would you want to take a nice, safe, optimized module that
> you have gone to the effort of type annotating and hide the annotations?

Agreed. We don't need to support switching.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/