[Types-sig] Syntax

[Paul Prescod]

Greg Stein wrote:
> 
> > lot of difference between the widely embraced Tim-syntax and the syntax
> > I posted a few days ago (based on the Tim-syntax). But if putting the
> > keyword "decl:" in front makes it feel better then I'm all for that!
> 
> Sorry. I won't let you rewrite history :-). You were suggesting a new,
> alternative syntax, rather than adding new syntax to Python. 

I was suggesting a new, alternative syntax that would eventually become
a part of the Python runtime system. I said that the new, alternative
syntax should go in separate files for now because that makes
implementation simpler. What I argued against was restricting ourselves
to Python as it exists today, in particular nested dicts and lists.

> Tim and I
> (and some others) have lobbied for adding new syntax. In particular, I
> don't want to see Yet Another Language and Yet Another Parser to deal with
> a distinct language/syntax for type specifications.

decl has a grammar. It *is* Yet Another Language. As Tim says, it is
rapidly approaching the complexity of Python itself. :) 

I am still guessing that for the first version it will also use Yet
Another Parser because I don't want to change the real Python parser
while we are in development mode. Are we going to set up our own CVS
tree and have all of our testers install a new binary when we change the
precedent of the ! operator or add a feature to the decl statement? I
would rather send them one or two new Python files.

*If* 1.6 is coming when we need it to, then we could give it a very
informal grammar for decl that basically stops at a comment or line
boundary. That could invoke our (Python coded) decl-parser. More likely,
we will want to test things out before 1.6 so we will probably stuff
decl statements into expression statement-strings or shadow files.
Either way, we have our own (sub-)grammar and (sub-)parser based, it
seems, on Haskell.

> Regardless: I'd hope that the first step to any implementation is to
> update the Python grammar and allow us to annotate existing Python
> programs (i.e. to use inline syntax). Updating the grammar is not super
> difficult, but I hear you about wanting to not use another binary. But
> I'll just shrug that off and say that's your problem :-)

Updating the grammar is not super-difficult but getting it right the
first time is difficult.

I cannot believe that nobody in parser-land has written a Python-based
Python parser that we can hack. Whatever happened to the ethic that a
parser-generator was not done until it could parse the language it was
written in? That a Real Programming Language was not done until it could
compile itself? :)

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
Three things see no end: A loop with exit code done wrong
A semaphore untested, and the change that comes along
http://www.geezjan.org/humor/computers/threes.html