[Types-sig] Conformance model

[skaller]

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