lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Well, it seems you are referring to the language syntax, whereas I was talking about the Lua/C API.

Which one do you think the original poster was referring to:

My wish: a stable API between versions. Every time Lua increments a version all the Lua DLL (and equivalent) users have a lot of back-end re-writing to do.

My 2c: syntax, let it change, if there's benefits. Consider Lua 5.2 a different language. Lua C/API, try to keep stable, or at least detectable which API version there is.

In practise, as Roberto points out in some of the pdfs/books, Lua 5.0 should have become a much more stable syntax than what Lua prior to that has been. So, apart from the now compulsory "pairs()" call in table recursion, is there something that's really really bugging you? Or just that you're afraid. Be not. :)


On Tue, 14 Nov 2006 12:21:27 +1100
 Mike Kreuzer <> wrote:
Sure, there are bindings & wrappers, but so far the ones I've looked at (& I haven't investigated yours) either act with the same carte blanche with regard to changing their APIs, or they don't update at all.

Not updating seems to be a popular choice, but what possible goal could be achieved by fragmenting the user base between different
versions of the language?

OK, I'll up the ante with Santa. Now I'd now like backwards compatibility for Christmas as well. From version 5.1, any 5.1 script should run in any future version of Lua. If the language is mature, and
I think it is, then it's time to say so.

The Oxford English Dictionary has a very simple rule for deleting a word once it's in the dictionary: They don't. I think we should adopt the same approach with language features. It might concentrate minds a bit
when new features are being considered.

Mike Kreuzer wrote:

Without taking stand as to the API question itself, the gluax module interfacing allows modules to be immune to this change. The same binary can be loaded into Lua 5.0, 5.1, and any foreseeable versions.

Personally, I think binary compatibility is not so essential, though. It suffices to be able to recompile, without changes in the source. Also in this gluax does help.

The technology was in use in LuaX, and is coming "out" in the new LuaX2 next year. As a new thing, modules can be compiled into standard Lua n.n modules as well, which should lower the bar for most people to try it out. I'm planning to roll this out in larger scale alongside the LuaRocks initiative (note: LuaRocks is in no way gluax dependent).

Tried to make this clear, but... it's easier to show the samples, really. :) I will.

Think of it as a higher level "bindings API", above the kitchen-door level Lua/C API.


On Mon, 13 Nov 2006 00:37:06 -0500 "Jérôme VUARAND" <> wrote:
That's a key specificity of Lua that its API is not stable. Lua is an evoluting language. You just have to look at Lua 4 manual to figure the heavy changes that have happened. Maybe you should consider each Lua version as a different language.

This may be a source of troubles for people having a large codebase relying on a specific API. For long term project you should stick to a specific version of Lua. But according to that page (, Lua 5.0 first alpha/beta releases are already 4 years old, and Lua 5.0 is still maintained and supported by the mailing list. I think it's quite a long time already.

Lua 5.1 has a lot of optionnal compatibility features that helps make the transition smoother. And Lua releases become more and more distant from each other. Lua 5.2 may take several years to come (the graph on that page looks like a reassuring exponential distribution :

My 2 (or 3) cents.

2006/11/12, Mike Kreuzer <>:
Just noticed some other 5.2 wish list items, and, well, Christmas
 is coming up. :-)

My wish: a stable API between versions. Every time Lua increments a version all the Lua DLL (and equivalent) users have a lot of back-end re-writing to do. Some is sometimes inevitable, but less would be better.

If a project takes several years to develop, and it's hoped that it'll be useful for several years after it's finished, that's two
lots of several years worth of stable API to aim for.

Regards, Mike Kreuzer