On 2 Dez., 14:57, lkcl <[EMAIL PROTECTED]> wrote: > as a general-purpose plugin replacement for /usr/bin/python, however, > it's not quite there. and, given that javascript cheerfully goes > about its way with the "undefined" concept, it's always going to be a > _bit_ tricky to provide absolutely _every_ language feature, > faithfully.
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 has JS 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. Regards, Kay -- http://mail.python.org/mailman/listinfo/python-list
