[Types-sig] Re: [Types Sig] Progress

[skaller]

Paul wrote:

>>>>
1. Most people seem to agree with the idea that shadow files allow us a
nice way to separate type assertions out so that their syntax can vary.
I think Greg disagreed but perhaps not violently enough to argue about
it. Interface files are in. Inline syntax is temporarily out. Syntactic
"details" to be worked out.
<<<<

I'm more interested in the inline syntax. Reason: it is easy to 
modify the Viper grammar to allow it. It is much harder to
build a completely new translater for a new 'type' language,
and, this will not sit well with Viper's "any object can be a type".
I also dislike maintaining separate interface files.
[i'm not against this, just stating something I dislike about it]

However, here is an idea for interface files:
an interface file is an ORDINARY python file.
No special stuff. Instead, a new keyword: 'defered'.
For example:

	def f(a:int, b:long): defered

'defered' has the same semantics as 'pass',
but it means 'we'll define this function later'.

The important thing, then, is that the interface file
has a different extension, so that a compiler
can get the type information, without building
the actual module, and it can match the interface
against the actual module. But 'defered' can be
used anywhere.

>>>>>
2. Everybody but me is comfortable with defining
genericity/templating/parameterization only for built-in types for now.
But now that we are separating interfaces from implementations I am
thinking that I may be able to think more clearly about
parameterizability. It may be possible to define parameterizable
interfaces by IPC8. Parameterization is in. Syntactic "details" to be
worked out.
<<<<<<<<

I agree: parameterisation is important. But I don't think
the usual notions used by static languages will work so well
in Python. Before proceeding, please consider how Viper
is supposed to do this. It's real easy to implement, and it
obviates the need for any special new syntax. 

>>>>>>>>>>>
3. We agree that we need a syntax for asserting the types of expressions
at runtime. Greg proposes ! but says he is flexible on the issue. The
original RFC spelled this as:  has_type( foo, types.StringType ) which
returns (in this case) a string or NULL. This strikes me as more
flexible than ! because you can use it in an assertion but you don't
have to. 
<<<<<<<<<<<

I don't think we agree on this: Guido says that assertions
are good enough. I wouldn't argue.

>>>>>>>>>>>
4. The Python misfeature that modules are externally writable by default
is gone. Only Guido has expressed an opinion on whether they should be
writeable at all. His opinion is no. 
<<<<<<<<<<<

I would like this. however a point: we can always write to
a class instance attribute instead. And this is just deferring the 
real problem. Another point: if 'defered' is accepted,
it could be OK to write ONCE to a defered variable
(and an error to use one that had not been written).

>>>>>>>>>>>>>>
5. It isn't clear WHAT we can specify in "PyDL" interface files. Clearly
we can define function, class/interface and method interfaces.
<<<<<<<<<<

Yes it is: if we have them, we have to be able to specify EVERYTHING.
:-)


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