[Types-sig] Conformance model
skaller
skaller@maxtal.com.au
Thu, 30 Dec 1999 12:03:55 +1100
Paul Prescod wrote:
> To faithfully represent CPython, an optimizing compiler would need to
> silently compile:
>
> jfoieawjofij
> fewajofijeawofj
> fjowiaejfowei
>
> to:
>
> raise SyntaxError
Precisely. In particular, assuming
the name 'silly' for the above module:
# module X
try:
import silly
x = 0
except SyntaxError:
x = 0
.. more code using x ..
clearly indicates why this is necessary with
the current specification, and why it is a bad
specification to optimise. Indeed, it is
lucky that 'SyntaxError' is a properly of a whole
file so that:
try:
lkjhglkjhsdf
lkhslkjhsdf
except SyntaxError:
....
raises a SyntaxError which is NOT trapped
by the except clause (since SyntaxErrors
are raised by the compiler, and apply to
the WHOLE file).
My argument is that this is what should be
specified for some other 'errors' in some
contexts. Given that python is dynamic,
my argument is that, say, for a type error,
it might make sense to ALLOW:
try:
1 + "Hello"
except TypeError: pass
but mandate that
def f(x):
1 + "Hello"
is not a valid Python program -- a compiler
can reject the program, rather than being
forced to implement:
def f(x):
raise TypeError
which is what is currently required.
in particular, most people who use
compilers RELY on the compiler, when it rejects
code, NOT providing a .o file, which prevents
the linker linking the code, which prevents
the 'erroneous' code actually being run.
C/C++ compilers are not required
to do this, but they're not prevented from
doing it either. A Python compiler would be,
if we do not modify the semantics.
At least as I see it, Greg in particular
is not seeing this project the way I am -- I see
that we are TRYING to make python LESS dynamic:
Guido never intended it to be as dynamic as it is.
That is, we DO NOT WANT to actually preserve the
existing semantics. We WANT to break some naughty
programs. It's desirable.
It's clear Guido agrees. He has been the leader
in suggesting changes to the specification supporting
this, including backing up, if not actually first suggesting,
the idea that
module.value = x
should be disallowed.
You just can't sensibly talk about adding
static typing to a language, without also saying
that some text is not IN the language: it is
ill-formed, invalid, an error, or just plain NOT PYTHON.
In fact, the more stuff we ban the better,
the condition we must observe is that we do not
break TOO much sensible code. Deciding exactly
what should be 'banned' is not easy, but it is not
even possible if don't first agree that things like
hgkjgaskhgad
khgsdfkhgsdfkhg
are not in fact valid Python programs.
BTW: this tract belongs in a thread marked 'conformance model',
rather than being mixed up with the static typing specification
as given in Paul's RFC. There is a relation, but I'd not
like the conformance issues to muddle, say, specification
of the static typing grammar extensions.
--
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