[Types-sig] check.py (was: PyDL RFC 0.02)

[skaller]

Paul Prescod wrote:
>
> My syntax is mostly based on your web page. I switched "!" for "as"
> based on my belief that it isn't Pythonic to use random keyboard
> characters in ways that are not universally understood.

	Then you had better think again. 'as' is an ENGLISH word.
English is not 'universally' understood.

> It is my personal opinion that the grammar should be the last thing you
> integrate into your system. 

	I don't agree. This viewpoint is equivalent to the old-fashioned
notion of top down analysis, in which a design is completed in every
detail before it is implemented. Object oriented programming is
utterly contrary to this paradigm, being bottom up: it specifies
bottom up development, with early coding of low level design parts.

	To be more concrete, what you are saying would require
a vast amount of human brain power, instead of permitting early,
partial implementations, which would allow machines to aid
in our analysis.

	I have implemented 'x!t' in Viper, and then, later,
I implemented 'def f(x!t)' -- the uses require grammar modifications
in different places and are technically distinct.

	As I am now implementing a C code generator, I am noticing
the effects of the optional typing on a compiler (although I'm
not actually using the information yet). 

	In particular, since my implementation is entirely dynamic, 
it fits well with cgen_module, which uses an already loaded module.
I have not tried a static compiler which 'parses' text to generate
code yet, but I suspect this will make my dynamic interpretation
difficult to implement -- on the other hand, Greg Stein HAS
tried this kind of tool -- and so I'd like to hear from him
what the impact of the 'at run time' meaning would be,
if he has looked at this.

>In order to avoid maintaining a whole
> compiler while the grammar shifts, I would suggest you define classes
> like this:
> 
> class ParameterizedInterface:
>         ....
> 
> class ConcreteInterface:
>         ....
> 
> class MethodSignature:
> 
> and so forth. You need these classes regardless.

	I don't. My implementation is ML based,
and the static compilations tools are likely
to use native constructions not Python ones .. although
I'm not sure.

	And in order to implement _anything_ I need
a starting point, which is a formal grammar for the syntax
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