merits of Lisp vs Python

[Kay Schluehr]

JShrager at gmail.com 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