merits of Lisp vs Python

Juan R. juanrgonzaleza at canonicalscience.com
Wed Dec 13 03:22:53 EST 2006


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.

> 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.




More information about the Python-list mailing list