merits of Lisp vs Python

[Kay Schluehr]

Juan R. schrieb:

> Kay Schluehr wrote:
> >
> > You mean a universal language adapter? I guess this is always possible
> > using alpha conversion but I don't believe this leads to theoretical or
> > practical interesting solutions but is just a limit concept.
>
> Not familiarized with you terminology. I think that i would call that a
> universal language composer.
>
> I mean if there exists some theoretical limitation to composionality of
> two directly collapsing languages (G1, T1) and  (G2, T2) via a
> unambiguous modification (e.g. 'renaming') to a third one (G2', T2'),
> unknown to me. I mean some theoretical limitation in the sense of known
> theoretical limitations to proving theorems in closed formal systems.
> After all proving a formal theorem is not very different from
> enhacement of a language.

But proving the theorem might be trivial and the implementation
useless. It's like saying you want "universal composition" of two
geometric objects e.g. two manifolds M1, M2 and I write down M3 = M1 x
M2. This is always feasible but this is just not the right kind of
thing in many occasions.

I want to give a practical example. The Python grammar defines a
compound_stmt rule by:

compound_stmt: for_stmt | while_stmt | if_stmt | ...

Now you might add a switch_stmt to G1 and a repeat_stmt to G2

G1: compound_stmt: for_stmt | while_stmt | if_stmt | switch_stmt |...
G2: compound_stmt: for_stmt | while_stmt | if_stmt | repeat_stmt |...

What you actually want in G3 is

G3: compound_stmt: for_stmt | while_stmt | if_stmt | switch_stmt |
repeat_stmt |...

You don't want to rename each statement and mangle each terminal of G2
although this might always be possible. Renaming also negatively
affects the transformer of G2 which precedes composition and is encoded
as Python source. It has to be refactored too when you rename a rule.

So one requirement on a system of composition rules is to drop alpha
conversion which is just a last resort. I guess in any *reasonable*
system of composition rules the question whether G1 and G2 are
composable is decidable and this can also be proofed at least for
certain classes of grammars that are not Turing complete languages by
themselves.

>
> > The practical problem with composing enhancements is that any two
> > extensions L1, L2 share a lot of rules and rely on their structure.
> > What if they don't just extend their host language L0 conservatively
> > but also redefine rules of L0? This is not just a theoretical problem
> > but it happens quite naturally if you want to adapt an extension
> > developed for Python 2.4 for working with Python 2.5. Here Python 2.5
> > is considered as just another particular extension. Obviously Py3K will
> > become an interesting testcase for all kinds of syntactical and
> > semantical transformations.
>
> I would consider redefined-L0 to be L0'. I think that a concept of
> namespaces could be also used for versioning-like conflicts:
> L0v24:foo(), L0v25:foo(). The problem is that both versions may be
> stored and managed during initial period of time. But in the long run
> old libraries, extensions... would be updated to the new version.

Sure, but it's preferable to see how far one gets without name mangling
and other crutches.