[Types-sig] Shadow File Opinions?

[Greg Stein]

On Wed, 15 Dec 1999, Christian Tismer wrote:
>...
> It doesn't matter if there is an extra file, or you insert a
> function call into your module, like
> 
> system.interface("""triple quoted string defining interface""")
> 
> without changes to the language but experimental syntaxes for
> these IF files/strings.

The compiler needs the information. This implies that you can't add the
information procedurally. The mechanism must be "transparent" to the
compiler.

> > But yes: it solves a short-term problem of "what is the syntax for
> > defining a module/class interface (its func and attr signatures)".
> 
> I think JimF has the best answer yet. Just look into his code.

I don't like the implementation at all (too many modules, too many "from
foo import ...), but the ideas seem to be sound. I believe there should be
a proposal for syntactical representations. The compiler can't pull its
information from JimF's current interface mechanism.

>...
> > 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.
> 
> Hmm, I hink the opposite is the way to go. Forget about type signatures
> for functions et al at all, just use interface info, and prove the
> interface by type inference.

The interface must be defined syntactically (or at least very
transparently to the compiler). Using a procedural mechanism only helps
with runtime issues. Given the presumption of syntactical interface
definitions, this leads to type signatures for functions.

> The interface is correct if and only if it can be proven.

This is a different problem, IMO. I would like to see interfaces used to
tell callers about the type information. I don't care whether the
interface is truly representative of the code or not.

> Given that, I see no reason to spoil Python with extra type
> annotation syntax. It's the other way round:
> If there is a correct interface, then type inference can be run
> in parallel as you are typing, like code colorizing, and python
> can tell you the set of types which any expression might have.

For runtime applications: yes. For compile-time static checks, you most
likely require new syntax.

>...
> What am I missing when I say:
> We need interfaces only and an inference machine to prove it,
> and that's all! Forget about extra info in the Python code.
> What would it help? I believe this is the whole story, and
> building upon JimF's startup, we would just need to write
> the inferencer now.

You're missing the requirement that a compiler must be able to extract
useful information. I'm not sure that a compiler cannot do this with the
current JimF proposal:
1) there is no mechanism for signatures (or a defined way for the compiler
   to extract/parse them)
2) procedural definition is allowed (e.g. instantiating Method()), which
   prevents the compiler from extracting the info.

New syntax, or well-known mechanism such as __types__ is needed. I believe
JimF's proposal could be used (pull the info from __implements__ and the
definition of the interface), but some of its dynamicism must be torched.
(and maybe where it is required, we only allow it in one or two specific
cases (internal to the Interfaces implementation) and then hard-code those
details into the compiler/inferencer).

Cheers,
-g

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