[Types-sig] PyDL RFC 0.02

[skaller]

scott wrote:

> This is why it seems to me that checks done at compile-time must be
> done based on a compile-time specific model of the namespaces, and
> that model must be more restrictive in naming and scoping usage than
> python currently is. 

	No: the way I see it, the 'optional type checking' when
added to the python language makes it more expressive, not more
restrictive -- even though constraints on declared names
are part of the extension, it is a genuine extension.

> Example restrictions that seem to help meet this
> end are: don't delete typed variables, don't use different types for
> variables at different times, unless that variable is pre-set as a
> union of both types, etc.

	This is correct. There must be a set of 'text files'
which are not valid python programs. As you say, assigning
the wrong type to a statically typed variable would render
the program 'not python': but this situation cannot occur
in python 1.5, because there are no static type declarations.

	What this means is that there are some
files which technically have incompatible semantics to Python 1.5,
technically, running these files currently requires a SyntaxError
to be raised. Under the modified semantics, there are two cases:
the program runs 'more or less as if the declarations were not there',
which will happen if the execution of the program obeys the
declared type constraints, or, 'the file is not valid python',
which means we don't care what happens. In the latter case,
a run time exception would be useful from a non-optimising
interpreter, and a compile time diagnostic from a type-checking
translator, but in those cases where, in particular, the type
checker cannot ensure the constraints are met, an optimiser
is entitled to ASSUME that they're met, optimise accordingly,
and core dump if, in fact, they're not.

	It is ALSO possible to _require_ a diagnostic
in some cases of an invalid program. But much care is need
specifying them, to make sure it is possible to for
_all_ language translators to detect
these cases. [And usually, what happens after that is
undefined anyhow]

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