merits of Lisp vs Python

[Kay Schluehr]

Kaz Kylheku wrote:
> Kay Schluehr wrote:
> > Juan R. wrote:
> > > A bit ambiguous my reading. What is not feasible in general? Achieving
> > > compositionality?
> >
> > Given two languages L1 = (G1,T1), L2 = (G2, T2 ) where G1, G2 are
> > grammars and T1, T2 transformers that transform source written in L1 or
> > L2 into some base language
> > L0 = (G0, Id ). Can G1 and G2 be combined to create a new grammar G3
> > s.t. the transformers T1 and T2 can be used also to transform  L3 = (G3
> > = G1(x)G2, T3 = T1(+)T2) ? In the general case G3 will be ambigous and
> > the answer is NO. But it could also be YES in many relevant cases. So
> > the question is whether it is necessary and sufficient to check whether
> > the "crossing" between G1 and G2 is feasible i.e. doesn't produce
> > ambiguities.
>
> See, we don't have this problem in Lisp, unless some of the transfomers
> in T1 have names that clash with those in T2. That problem can be
> avoided by placing the macros in separate packages, or by renaming. In
> In the absence of naming conflicts, the two macro languages L1 and L2
> combine seamlessly into L3, because the transformers T are defined on
> structure, not on lexical grammar.

Renaming is of course feasible too but it has to be done manually and
likely involves the change of some keyword. If both L1 and L2 define a
repeat_stmt with slightly different semantics they can't be combined -
renaming of rules is not always a big problem since a new package is
created for L3 anyway and scripts that work with L1 and L2 are at least
binary compatible with L3. The clash happens when one tries to edit an
L2 script in an L3 context. One has to refactor it regarding the
renamed rule ( this can very likely be done automatically ).

Since the rule definitions originate in different packages ( each
language is created in an own package ) there is basically no conflict
and one can switch between L1 and L2 and also import L1 in L2 or vice
versa but this is not the kind of composition I intend since one can't
really nest the statements/expressions made in L1 with those made in
L2.

> The read grammar doesn't change (and
> is in fact irrelevant, since the whole drama is played out with
> objects, not text). In L1, the grammar is nested lists. In L2, the
> grammar is, again, nested lists. And in L3: nested lists. So that in
> fact, at one level, you don't even recognize them as being different
> languages, but on a different level you can.

I don't see how this differs. A grammar G is just a "script" written in
another language ( say EBNF ) which can be represented within the sytem
as just another grammar. The internal representation of G is that of a
list of lists. While the programmer manipulates the surface structure
of the Grammar script which could be represented in whatever she likes
( currently as plain text but maybe also as a graph using dot and
graphviz or in any other slick way an UI designer imagines ) all
internal operations are defined on nested lists i.e. objects.