[Types-sig] Basic questions

[Martijn Faassen]

Paul Prescod wrote:
> 
> Martijn Faassen wrote:
[snip] 
> > * inheritance
> >
> > I haven't seen too much discussion on how types are going to interact
> > with the inheritance system.
> 
> I think it would work more or less as it does in other object oriented
> languages. I, personally, am concentrating on the parts of the system
> that I feel I don't understand. 

Okay, I'll focus away from inheritance for now.

> Those parts mostly have to do with
> Python's dynamism and not with its already existing type system. Of
> course subtypes of "foo" should follow "foo"'s interface and should be
> recognized as "foo"s.
> 
> But the much more basic question is whether:
> 
> class foo: pass
> 
> even *defines* a type that can be used in type declarations. Greg says
> yes, even if the declaration is buried in code. Tim says no,(I think)
> not unless it is preceded with a decl statement. I'm trying to figure
> out which one is right.

I'm in the make it explicit camp here. Nothing defines any type
(functions or classes) unless we explicitly say that it does. Otherwise
it may default to 'everything is the Any' type which should be
equivalent to basic Python. Note that we will probably lose static type
info in any code path that passes through basic Python, to any path
exiting Python into statically typed Python should have runtime checks
(or give compile time errors). I wonder if in practice this will mean
people will start to assign types to *everything* to make it work well
(or efficient) with types at all. If so then we need to somehow avoid
this.
 
> We can get to inheritance and interfaces later.

I actually need interfaces in my following discussion, so I apologize in
advance. :)
 
> Basic questions.
> 
> 1. Is this valid:
> 
> class foo: pass
> 
> def a( arg: foo ): pass

Not unless somewhere it says explicitly that class foo defines a static
type, I'd say.
 
> 2. Is this valid:
> 
> if someFunc():
>         class foo: "abc"
> else:
>         class foo: "def"
> 
> def a( arg: foo ): pass

This is the really interesting one.. Perhaps interfaces can help here.

One rule could be this:

You can't define the same name multiple times in the same scope. You
have to do  'class foo1' and 'class foo2' instead, and then say they
both conform to the interface 'foo'.

Consequences:

* A separate interface declaration syntax would seem to be required.

Consequences I describe at the alternative rule apply too, I think.

An alternative rule would be the following:

Any class names that are defined multiple times in the same scope are
taken to support an interface with that same name. This interface is the
only type you can use elsewhere; you can't use the class type directly.
It is a compile time error if classes with the same name define
different interfaces. 

Consequences: 

* This may mean we enter access-rule land; it would be okay classes
conforming to an interface to define different member variables, as long
as these are private.

* The interface needs to be hooked up to the actual implementation
during runtime. This may happen as soon as a class (that the compiler
has seen has multiple definitions) is actually being defined at
run-time.

* These are odd interfaces in the sense that it looks as if you can
instantiate from them! What 'in fact' happens is that the interfaces
passes any instantiation requests to the actual class that's doing the
implementation -- the interface is a simple factory.

The same story would apply to function signatures/prototypes; if the
same function name occurs multiple times in the same scope they're all
taken to define the same prototype, which would be the actual type used.

Regards,

Martijn