[Types-sig] Basic questions

[skaller]

Paul Prescod wrote:

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

	Sure, but how do you know what types are subtypes?
You cannot tell from inheritance: subtyping isn't related
to inheritance, at least in Python (same in ocaml).

	Example:

	class Foo:
		def f(x): return None
	class Bar(Foo):
		def f(x,y): return int(x)+int(y)

Foo is a base of Bar, Bar is not a subtype of Foo.
Classes do not specify types. They are simply constructions
which make constructing instances easy: all the instances
have the same type, Instance... you could argue that
instances of a particular class X have type 'Instance of X',
but the behaviour is only default (since attributes can
be dynamically altered).
 
> But the much more basic question is whether:
> 
> class foo: pass
> 
> even *defines* a type that can be used in type declarations. 

	The declaration defines a class.
It specifies the initial attributes of the class.
In CPython 1.5 at least, class declarations do not
define types. If you expand the syntax so that,
if the type is Instance, then you can give a class
name instead, then this would imply that _any_ class
object which can be refered to can be used.

	If I may: there is an issue here which
some people may not have realised: recursive types.
In an interface file, this can be handled by 
two passes.

	In implementation files, it is much
harder, since scoping rules are dynamic.
This is a good argument for interface files.
Example:

	class X:
		def f(y:Y): ...
	class Y:
		def g(x:X): ...

Resolving this in a single pass requires
backpatching, which is messy: but using two
passes leads to difficult ambiguities
due to renaming:

	class X:
		def h(): ...

Ok -- so now, which X does the X in g refer to?

In python, names are bound dynamically, which resolves
the problem. In an interface file, renaming can be banned.
Can it be banned, for classes, in implementation files?

-- 
John Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia
homepage: http://www.maxtal.com.au/~skaller
voice: 61-2-9660-0850