[Types-sig] Issue: definition of "type"

[Greg Stein]

On Mon, 20 Dec 1999, Martijn Faassen wrote:
> Paul Prescod wrote:
> [snip]
> > I'm on the fence about this last requirement because I would like to
> > think that all of the code out there with class statements is *already*
> > defining a bunch of types. A minority of it depends on runtime
> > information and we can easily detect those cases. So why not let the
> > simple case of "defined class that doesn't depend on runtime
> > information" be a shortcut for a type declaration?
> 
> Are you sure that in fact a minority depends on runtime information?
> Often Python code is used without any inheritance link, like this:
> 
> class Foo:
>     def doSomething(self):
>         ...
> 
> class Bar:
>     def doSomething(self):
>         ...
> 
> a = [Foo(), Bar()]
> 
> for el in a:
>    el.doSomething()
> 
> Doesn't this rely on run-time information? How would a type system deal
> with this? I suppose I'm entering the domain of interfaces now...

The type of "a" is a List where the elements' type is the union of the
type of each initialization value. In this case:

typedef a == typedef [Foo or Bar]

Pretty straightforward, but I'd be happy to detail this.

When the checker gets to el.doSomething, it knows that the type of el is
"Foo or Bar". It then goes through each alternative and verifies that
".doSomething" is legal for that possibility.

No problem :-)

Cheers,
-g

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