On Tuesday 19 Apr 2005 20:24, Guido van Rossum wrote:
..
> *If* we're going to create syntax for anonymous blocks, I think the
> primary use case ought to be cleanup operations to replace try/finally
> blocks for locking and similar things. I'd love to have syntactical
> support so I can write
>
> blahblah(myLock):
> code
> code
> code
I've got a basic parser that I wrote last summer which was an experiment in a
generic "python-esque" parser. It might be useful for playing with these
thing since it accepted the above syntax without change, among many others,
happily. (Added as a 38th test, and probably the sixth "language syntax" it
understands)
It's also entirely keyword free, which strikes me as a novelty.
The abstract syntax tree that's generated for it is rather unwieldy and over
the top, but that's as far as the parser goes. (As I said I was interested in
a generic parser, not a language :)
The (entire) grammar resulting was essentially this: (and is LR-parsable)
program -> block
block -> BLOCKSTART statement_list BLOCKEND
statement_list -> statement*
statement -> (expression | expression ASSIGNMENT expression | ) EOL
expression -> oldexpression (COMMA expression)*
oldexpression -> (factor [factorlist] | factor INFIXOPERATOR expression )
factorlist -> factor* factor
factor -> ( bracketedexpression | constructorexpression | NUMBER | STRING | ID
| factor DOT dotexpression | factor trailer | factor trailertoo )
dotexpression -> (ID bracketedexpression | factor )
bracketedexpression -> BRA [ expression ] KET
constructorexpression -> BRA3 [ expression ] KET3
trailer -> BRA2 expression KET2
trailertoo -> COLON EOL block
The parser.out file for the curious is here:
* http://www.cerenity.org/SWP/parser.out (31 productions)
The parser uses a slightly modified PLY based parser and might be useful for
playing around with constructs (Might not, but it's the reason I'm mentioning
it).
The approach taken is to treat ":" as always starting a code block to be
passed. The first token on the line is treated as a function name. The idea
was that "def", "class", "if", etc then become simple function calls that get
various arguments which may include one or more code blocks.
The parser was also written entirely test first (as an experiment to see
what that's like for writing a parser) and includes a variety of sample
programs that pass. (39 different program tests)
I've put a tarball here:
* http://www.cerenity.org/SWP-0.0.0.tar.gz (includes the modifed version of
PLY)
* Also browesable here:
http://www.cerenity.org/SWP/
* Some fun examples:
* Python-like http://www.cerenity.org/SWP/progs/expr_29.p
(this example is an earlier version of the parser)
* LOGO like: http://www.cerenity.org/SWP/progs/expr_33.p
* L-System definition: http://www.cerenity.org/SWP/progs/expr_34.p
* SML-like: http://www.cerenity.org/SWP/progs/expr_35.p
* Amiga E/Algol like: http://www.cerenity.org/SWP/progs/expr_37.p
Needs the modified version of PLY installed first, and the tests can be run
using "runtests.sh".
Provided in case people want to play around with something, I'm happy with the
language as it is. :-)
Best Regards,
Michael,
--
Michael Sparks, Senior R&D Engineer, Digital Media Group
[EMAIL PROTECTED],
British Broadcasting Corporation, Research and Development
Kingswood Warren, Surrey KT20 6NP
This e-mail may contain personal views which are not the views of the BBC.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
