[Types-sig] Basic questions

[Greg Stein]

On Mon, 20 Dec 1999, Martijn Faassen wrote:
>...
> > 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'.

Icky. No way.

Even if I didn't believe that the inferencer could resolve the above code
fragment, I wouldn't like having to use different names. That feels like
too much of an imposition (on the part of the type-checker) onto my code.

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

Nah. A class implies an interface.

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

The typedecl is a union of the two (implied) interfaces. No reason to
impose a single interface or to refuse the usage of the class name.

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

I don't see this happening.

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

I do agree that a class object would have an associated typedecl object at
runtime. The typedecl would define the class' interface.

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

I disagree. I would say the interface is just another typedecl. And
typedecl objects are not callable (and are certainly not factories).

Even if you wanted to make an interface instantiable, that just can't
happen: an interface could be used by multiple classes.

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

Again: I disagree. The inferencer would associate different typedecl
objects (signatures) with the name at different points in the execution.
Depending on the control flow, each redefinition will cause a union of
typedecl objects, or a replacment.

Cheers,
-g

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