[EMAIL PROTECTED] schrieb: > Now, speaking as a scientist, permit me to make a small practical > suggestion: Why not just figure out a way to simplify some brand of > Python -- make parens (or whatever) optionally replace whitespace and > line breaks as syntax -- and then add a simple macro facility -- macros > are actually a very simple extension if you have homogenous syntax, > homogenizing your syntax to the point where macros are possible is the > hard part -- and just see what happens.
The problem is not so much to add a macro facility ( or source transformer ) but to soften it and make the macro facility actually *simple* to use. Note that you don't need to replace whitespaces. The Python parser is LL(1) and whitespace is almost completely abstracted away once the Python source was tokenized successfully ( there is exactly one non-terminal in the Python grammar, the "suite" NT, that uses INDENT and DEDENT as moral equivalents for left- and right parens ). Note also that a homogenous syntax is not that important when analyzing parse trees ( on the contrary, the more different structures the better ) but when synthesizing new ones by fitting different fragments of them together. There are two basic approaches. In one you start with a piece of source code ( a template ) and enhance the source description slightly with somewhat like template parameters that keep source fragments and expand them. In this case you also need an unquoting mechanism or a way to evaluate code within the template. The second approach acts with high level wrappers of more low level source trees ( just like ASTs are high level wrappers of concrete syntax trees in most languages ). In Python one might even use operator overloading to hide the AST structure and provide a more convenient syntax. But this only describes the transformational aspect. The definitional part is not less important. I try to consider a grammar description of a full programming language as as script in an own little language ( actually it is and the grammars grammar is often just an EBNF grammar description ). This however presumes that enhancing grammars to enhance languages is a reasonable approach not just in a Lex-Yacc ( or ANTLR ) setting. The next question concerns compositionality of language enhancements or composition of even completely independent language definitions and transformers both on source and on binary level. While this is not feasible in general without creating ambiguities, I believe this problem can be reduced to ambiguity detection in the underlying grammars. > One of two general things are > likely to happen: Either people will not use them, and they will > languish and die, and then at least you can say; "Been there, done > that" to the Lisp community. Or, more likely, the some subset of the > Python community will get it, and will figure out how useful they are, > although it might take some time. And then you might find yourself with > a wonderful new tool. I think so too. > You might even get a compiler out of the deal, at > a pretty low cost, too! If you get macros, and get a compiler, I'm > pretty sure that you will have no problem winning over the Lisp > community, who would LOVE to have your extensive libraries, and that > you will probably be able to maintain and improve your flagging > position wrt Ruby (which, according to Matz, is more-or-less just Lisp > w/o macros.) Just a moment ago you called programmers of other languages "flies" which I found annoying and now you offer LOVE in big letters? I don't even think the "competition" to Ruby matters. Once an easy to use metaprogramming system could be done for Python it could be ported with some adaptions to other languages with more "complicated syntax" ( non LL(1) parsable ). Kay -- http://mail.python.org/mailman/listinfo/python-list