[Types-sig] Scarecrow Proposal

[M.-A. Lemburg]

I've just read the Scarecrow Proposal and have a few questions
(sorry, if these have already been answered at the conference...
I haven't been there):

· Why is it important that classes and interfaces are different ?

Is this just to make sure you can't mix classes and interfaces
in __bases__ ? IMHO, we should use as much as possible from the
existing features, so I think building the interface hierarchy
with plain Python classes and then sticking them into the class
hierarchy as __implements__ (should probably be named __interfaces__;
a builtin function implements() could take care of the actual
lookup in whatever is suitable).

If there are strong reasons for making the two different in the
sense that type(class) is not type(interface), then I'd opt for
simply cloning the class implementation by creating a second
type object that is simply a copy of the class' one.

· Would this proposal get us closer to static typing ?

I'm thinking of a way to declare a named object ABC as having
an interface XYZ (e.g. a function could be assigned an interface
stating that the first argument must be an integer).

Since the interface hierarchy is something that is built dynamically,
the compiler would have to be given two things: an already executable
script INT that builds the interface hierarchy and the source script SRC
referring to this hierarchy. It could then optimize e.g. the function
calls
to abc knowing that the first argument is an integer and also add
checks at C level to ensure this (a PyInt_Check() is a whole lot
faster than the same check via type() in Python).

A general syntax would have to be introduced to accomplish this
(which would have to go into Python 2.0 I presume), e.g.

def ABC(a,b,c) implements TypedArguments(Integer,Any,Any):
    a = a + 1
    return a, b+c

where TypedArguments is a helper function defined in the INT script
which creates an interface for the given argument combination (Integer
and Any would also have to be defined in INT and the compiler could
call methods on these to find out how to optimize them). 

Note: The helper function would have to be called at *compile time*.

Also note: The code INT could have been imported by the compiler
as module prior to compilation, e.g. if there were a standard
hierarchy available no extra fuzz would be implied for the
compilation step.

· In any case, is the interface proposal going to effect any
  existing code ?

I would like to see it implemented as additional useful feature,
but in a way that is orthogonal to the existing implementation.
Especially: no performance hit if you don't use it.

· Should interfaces also allow changing the method invokation
  behaviour ?

E.g. pre- and post-conditions could be defined in the interface
rather than in a meta-class. When the compiler sees a method
ABC_precondition in the interface it generates code to call
this function prior ABC. Same for ABC_postcondition.

Do these Eiffel constructs belong into interfaces ? IMHO, they
do.

-- 
Marc-Andre Lemburg                               Y2000: 404 days left
---------------------------------------------------------------------
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :
           ---------------------------------------------------------