[Types-sig] RFC Comments

[skaller]

Paul Prescod wrote:

> 
> >         No, you mentioned it in point 5. :-)
> 
> Okay, you win. Const is out for now.

	Make an appendix for 'to be considered' items.
 
> > So: we have to be able to load an interface, without
> > that necessarily implying the module be imported.
> 
> I see why you would sometimes only care about interfaces and not about
> implementations but I do not see what it harms to do a "real import" of
> the module. 

	I do, I will try to explain, but the reason is that it is
inconsistent with the compilation module you specified, at least
as I understand it.

	The way I undertand it, a new-fangled python language
translator is required to behave 'as if' two passes are performed
on script: the first pass gleans static type information,
but generates no executable code, while the second generates
executable code.

	In this 'two pass' model, it is inconsistent to
'import' a module in pass 1, since 'importing' a module
requires a recursive tranlation pass involving TWO passes,
and we know that the second pass can even involve recursive
module execution. So it isn't _possible_ to import
a module during pass 1. It won't work.

	It _is_ possible to import only the interface
of a module, and this should be done when 'import X' is
seen. In pass two, a full two pass importation is triggered,
but the interface loading is skipped because the interface
is already loaded. However, the import still requires TWO
passes DURING PASS 2, because the implementation file
may also include inline declarations. It follows FROM THE MODEL
that these declarations are effectively private.

	You _could_ change the detail of the model
which makes that so, to perform pass 1 on the implementation
file during pass 1. I'm not sure what the impact is,
or what your intent is. But one thing you cannot do is
actually import a module during pass 1.

	Summmary: pass 1 processing only permits
pass 1 processing to occur recursively, whereas
pass 2 imports may invoke  a full two phase translation.

	So because the semantics of importing a module
(two passes) are quite distinct from only importing
interfaces, and even that has two possible variants,
it seems useful, if not essential, to permit a 
pass 1 only kind of importation -- 'include'.

> > The reason I chose "!" for argument declarations was that it
> > was already being used in similar way for the _expression_:
> >
> >         y = x ! t
> >
> > and in this context, ":" cannot be used.
> 
> Right. My RFC uses a function call syntax inline. It seems more Pythonic
> and can cause no no precedence confusion. It is also compatible with the
> Python 1.5.x grammar.

	Yes, but it cannot be used for function parameters.
This IS an 'inline' use, even though it is distinct
from a run time expression check (being applied to 
the parameter, syntactically, not the argument).
 
> I used "as" everywhere else. The colon was just a lapse.

	OK.

	I like '!' because it is terse. 'as' requires
four characters (two spaces are needed). This will
clutter function definitions:

	def f(self as X, x as X, y as X) ..

	def f(self!X, x!X, y!X)

but my taste is only a minor point here, I'll run with 'as'
if that is the final choice. But your use of a function
call like:

	interface_check(x,i)

for a run time test is not as simple as reusing "!"
for the same purpose: you could specify

	(x as i)

be allowed in an expression instead -- I know this
cannot be ambiguous, because 'as' is a keyword,
and so is '!', and I have implemented the latter.

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