[Types-sig] List of FOO

[skaller]

Paul Prescod wrote:
> 
> Thanks for describing how viper does parameterized types. There are a
> couple of things that I don't understand:
> 
> skaller wrote:
> >
> >         PyListOfInt = PyListOf(PyIntType)
> 
> But does this involve executing arbitrary code defined by PyListOf? 

	Yes.

> That would hurt our ability to do static type checking.

	I'm not so certain. I think you have asked the right question.
Here's why I'm uncertain: the code for PyListOf is written in Python.
Typically, it will be a simple class. A compiler or other static
analysis tool can analyse that code just like any other.

	Now, for _builtin_ types, it will surely help to
have _builtin_ semantics, and this is possible, because
Python does have a specification for these types.
For user defined types, it isn't clear analysing a type object
is that much harder or different, to analysing any other python
code. 

	Compare with analysing the behaviour of class instances,
tracking which classes they are statically. I'm not sure it
is much different. In fact, __getattr_ and friends already make
analysis of user defined classes difficult .. so perhaps
there isn't much difference here. I don't (yet) know.
 
> >         x.append(1)
> >
> > ends up calling
> >
> >         PyListOf.append(PyIntType, x, 1)
> >
> > which means it can check that 1 is of type PyIntType.
> 
> Right, but what is the declaration for append and how does it say that
> it takes a single argument and the argument must be of type PyXType
> where X can vary?

	Well, in Viper, the definition of append would be in the
class PyListOf:

	class PyListOf:
		...
		def append(Type, object, value):
			if type(value) is not Type):
				raise TypeError
			else:
				object.append(value)


Now, here, using a "Guido rambling argument" I think you ( a human )
could deduce what is going on. The explicit type test indicates
typeness of value: it tells that the type of  value in 
object.append(value) must be Type. It is harder to deduce
that 'object' is a list. Indeed, it might not be, it can be
anything with an append method. Hopefully, the definition
I gave won't lead to an infinite recursion. 

	I guess the point I'm making is: suppose the
Viper type system works out nicely for the interpreter.
Then this suggests a more 'pythonic' way of naming types,
the way python programmers do it now:

	type([1,2,3]) is types.ListType

	type(user_object) is user_module.MyType

where the RHS in both cases is a python expression
denoting a type object.

The reason I'm suggesting this is worth examining,
is that it doesn't require much change to python:
the CPython currently uses special type objects for
types ... but JPython is a bit different, and Viper
just generalises CPython a bit.

At least one advantages is that C extensions are well
covered by this idea. No, I should say "it seems to me
that this might work well with C extensions, possibly
better in Python 2 than 1.6 (since the architecture
of Python 2 will be reworked)". Might also work
better for JPython too.

Note I'm not against using a functional language's
type description for Python, a'la Tim/Haskell,
but it isn't clear that is going to work well either,
and it seems to involve 'extra' work, writing a parser
for a 'new' language, etc.

I think you said 'ignore non builtin types
for the moment', and I think I'm giving an argument
that this might not be such a restriction after all.

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