[Types-sig] typedefs (was: New syntax?)

[skaller]

Greg Stein wrote:

> > Yes, but you basically have the same setup with current Python if you
> > exclude Lambdas. A function definition is merely used to create an
> > 'alias' for a piece of code, to clarify other pieces of code. If you
> 
> I disagree that a function def is merely an alias. It provides a new
> namespace, parameter binding, and capabilities such as deferred execution.
> I definitely don't see it as simply an alias.

Greg is correct in at least one sense: when a 'def' is executed,
the function is given a particular name which can be retrieved,
the same applies to classes. These names are independent of a
variable which happens to be bound to the function or class:

	def f(): pass
	g = f
	del f

The function refered to by variable g has name 'f'.
Def is not an alias for a lambda, even if lamda were
extended to provide a suite in which statements could
be written and locals exist.

The case of functions is not interesting here, but the case
of classes certainly is, a point I missed in a previous post.
When a class is refered to in a type declaration, we have
to decide if the reference is an evaluable expression,
or is the name of a class -- independent of any variables.

In the second case, we must disallow two classes having the same name,
or permit an ambiguity in the type declaration. 

I'm half guessing that Guido would be happy to prohibit
definition of two classes with the same name.

Unfortunately, this leads to a problem: clearly this
restriction is not global, but only 'per namespace'.
Which opens up the question: how are namespaces
identified. For modules, the module name?
For functions, the function name? 

Sounds good: we can ban duplicate definitions 
of classes, identifying a class by its fully
qualified name: the full package name of the
containing module, then any enclosing functions
and classes, finally the class name.

But note that for a class enclosed in a function,
the class has a transitory life. So in this case,
it isn't clear that static analysis means anything,
since two _distinct_ classes can have the same name
at different times. This also applies to
other scopes, where class objects can be deleted.

To make the issue even more complex, the lifetime
of a class is not determined solely by the existence
of a variable bound to it -- since a class can be a 
base of another, or refered to by one of its instances.

So a ban on duplicate names might be hard to enforce,
and wouldn't make any sense in the function case ..
so I'm half guessing Guido will not be so happy
to ban duplicate definitions :-)

Now, where does this lead? I think it leads to
a requirement for syntax to _specify_ a class is
static. In this case, the class is immortal,
will not be deleted, and no other of the same
name may be created. And THEN, we can use
the class names in type declarations (of function
parameters).

Summary: if you want a function parameter to have
a specified class type,  then the class definition
must be specified as static.

This can be assumed in an interface file,
but must be specified by additional syntax in an implementation
file.

It looks like Guido is right: interface files are the only
way to get enough control to actually do static analysis/checking,
without adding a lot more syntax to the python (implementation)
language.

BTW: I want to propose some terminology here: when a type
declaration is given in a function definition, that
declaration is called an INLINE declaration,
to distinguish it from a declaration in an interface file,
or a stand-alone prototype which is not a definition.

	def f(x : Int): ...
	        ^^^^^
	this is an INLINE declaration

given that terminology, it would seem that
inline declarations cannot work well UNLESS
there is also a non-inline declaration of the type
being used (Int in the example).

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