kay.schluehr at gmx.net
Tue Dec 2 18:15:16 CET 2008
On 2 Dez., 14:57, lkcl <luke.leigh... at googlemail.com> wrote:
> as a general-purpose plugin replacement for /usr/bin/python, however,
> about its way with the "undefined" concept, it's always going to be a
> _bit_ tricky to provide absolutely _every_ language feature,
For some reasons I'd do it the other way round and model JS entirely
in Python first. This is rather gratefully supported by two facts
1) Python is far more powerful than JS and supports lots of
metaprogramming facilities. For example providing a Python type that
prototype semantics isn't really a big deal.
2) JS is standardized and the standard is very well documented.
When JS has been mapped onto a dedicated Python framework one can open
the backchannel and translate the Python framework code to JS. Ideally
the mapping P_JS -> P_PyJS -> P'_JS is an identity. PyJS is
unambiguously fixed by this mapping.
Now people may define mappings from Python types to PyJS types and all
the checks and tests are performed as usual checks in Python code by
API functions of the PyJS framework. The compiler hasn't anything to
do with it anymore and can be somewhat liberated from hard work. This
roundtrip breaks with the GWT scheme of one way translation for an
obvious reasons: Python is not Java.
More information about the Python-list