On: Compiling to Lua

[Raphael_Amiard]

Not really. If you want to compile down to Lua you have to either :

1. Accept Lua semantics (for example, numeric semantics) 2. Accept a (severe) performance hit in thoses cases where you want to have different semantics.

Disclaimer : I actually had this very idea and tried to make a Python to Lua compiler. Since my reason was to see if Python on LuaJit could be faster that CPython, i quickly realized this wasn't possible if you wanted to fully respect python semantics.

OTOH you could do a language that is very close to Python semantics and very close to Lua(JIT) performance, if you accept to deviate in a few points.

[chalst → Raphael_Amiard]

Numbers: there's no issue with handling numbers using userdata. See how lgmp handles this [1]. There's a wider issue of just how Lua is the target language if most of the runtime and much of the semantics is being done in C libraries...

Which Python constructs in particular did you think were tricky? I had thought a bit about the special case of modelling Python comprehensions and decided that they translated nicely, but I might be deluding myself since I implemented nothing.

[1]: http://members.chello.nl/~w.couwenberg/lgmp.htm

[jerf → chalst]

Implementing a Python-ish language is easy enough. Depending on your definition, Lua already is one. Implementing the totality of Python is very hard to do performantly. Anything you think you can cache can probably have that cache violated, and real code will tend to do it. For instance, surely you can just cache a class -> method table once? My goodness, no. The class can be dynamically modified, including rewriting what methods exist. This happens in, for instance, interpreter reloads, so it's a real problem. An instance can have a method dynamically overloaded. (Prototype inheritance is not supported by the language's style or keywords, but it is essentially supported by the semantic model.) Heck, an instance probably isn't what you think it is, check this out (tested in Python 2.7.4 and 3.3.1):

    >>> class A:
    ...     def method(self):
    ...             print("A")
    ...
    >>> class B:
    ...     def method(self):
    ...             print ("B")
    ...
    >>> a = A()
    >>> a.__class__
    <class '__main__.A'>
    >>> a.__class__ = B
    >>> a.method()
    B

"Aaaaaaaaa!" goes the interpreter implementor.

It's not the raw syntax that is hard, it's the mutability of everything, you know, a user gets an instance of something, adds an overload of the __add__ operator to just that instance which then proceeds to change the class of the other element of the addition operation... sure, it doesn't happen often but it happens often enough you can't just ignore it, unfortunately, or what you've implemented isn't Python anymore.

[chalst → jerf]

I'm convinced that this is a hard task, hard enough that probably no one will do it properly. But for emulating Python class semantics, is there any reason why we can't:

1. Come up with an inefficient but exact modelling of the semantics in pure Lua using tables and metamethods. I think I can write metamethods showing exactly the behaviour you describe.

2.Come up with an efficient implementation of python_class userdata?

The problem you describe is the problem of really understanding what's going on, not a deficit in Lua's ability to model it.