[Types-sig] Shadow File Opinions?

Christian Tismer tismer@appliedbiometrics.com
Wed, 15 Dec 1999 15:06:09 +0100


Greg Stein wrote:
> 
> On Tue, 14 Dec 1999, Paul Prescod wrote:
> > Martijn Faassen wrote:
[- seperate IF files, forget about syntax -]

[Paul]
[- compatibility for free, plus IDL option -]
[- IF files for all modules possible -]
> > Do others agree?

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

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.

> 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.

> 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 is correct if and only if it can be proven.

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.

I'm telling types by using stuff with known type. That is either
literals, or functions which come from other modules which
already have an interface. At any time, my IDE can tell me what
type the object at the cursor has, nad worst case this is
just PyObject.

The empty interface which just says "every visible is exported"
and "everything is a PyObject" is always fulfilled.

An interface which specifies restrictions on input values
(as parameters to functions and arguments of setattr calls of
objects) provides the information which is used to calculate
types in your code.

An interface which restricts output values
(function return values and results of getattr calls of
objects) provides the constraints which have to be proven.

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.

not-trying-to-say-this-were-easy - ly chris

-- 
Christian Tismer             :^)   <mailto:tismer@appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.python.net
10553 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     we're tired of banana software - shipped green, ripens at home