Re: Clean Lua

[Hisham <hisham.hm@...>]

On Fri, Nov 18, 2011 at 11:27 AM, Dirk Laurie <dirk.laurie@gmail.com> wrote:
>
> 2011/11/18 Francesco Abbate <francesco.bbt@gmail.com>:
> >
> > I'm also among the Lua users that are not waiting for 5.2. It seems to
> > me that you break the compatibility, eliminate some useful things to
> > add some dubious minor improvements.
> >
> > This is of course just my point of view but it seems that the
> > transition to Lua 5.2 costs a lot and the benefits are dubious or
> > non-existent at all. Probably the only interesting improvent is the
> > "yieldable pcall and metamethods".
> >
> > Also the addition of the "goto" statement completely defeats my
> > understanding.
> >
> > I will personally not switch to Lua 5.2 as long as I can.
> >
> > Please understand that I don't want to be polemic here I'm just
> > expressing my humble point of view about Lua 5.2.
> >
>
> Just as Lua is written in "clean C, the common subset of Standard C
> and C++", one can write one's new programs in "clean Lua, the common
> subset of Lua 5.1 and 5.2".  Here is a partial list.
>
> 1. unpack = unpack or table.unpack
> 2. Don't use # or the table library on non-sequences.
> 3. Don't use goto.
> 4. Write modules to return a table containing everything and load them by
>    mymod = require "mymod"
> 5. Load bit32 explicitly if you need it.

Is this list complete? I think I may end up having to write some Clean
Lua at some point (actually, worse: convert Lua 5.1 code to Clean
Lua), and a reference like this would be very handy...

Sometimes I suspect that the project I work on (LuaRocks) does not use
Lua the way the Lua authors intended:

lhf wrote:
> You seem to misunderstand the dynamics of Lua. You never just upgrade Lua,
> you consider if the new Lua is good for your needs and then adapt to it.
> Lua is not like Firefox...
>
> You can keep whatever version of Lua is suitable for your needs *forever*.
> Just freeze the source code into your project.
> Many people have done just that...

I don't think I am in a position where I can do that. Can I simply
freeze LuaRocks in time and declare it is a "Lua-5.1-based project"?

I haven't even made the slightest move to port LuaRocks to Lua 5.2 yet
and there's already people complaining about its lack of support for
5.2:

Peter Drahoš wrote:
> LuaRocks is a great attempt to make a cross-platform Lua distribution but it
> has design flaws that have become apparent with the move to Lua 5.2

So this basically means I will have no choice other than to support
Lua 5.2. People *will* "just upgrade Lua" and expect LuaRocks to work.

I'm faced with few options:

* maintain two LuaRocks source trees, which I don't have the resources to do.

* keep using LuaRocks with Lua 5.1, even to maintain Lua 5.2 module
trees. Some people are already doing this with patched LuaRocks, but
as Lua 5.2 gains traction, I suspect people will consider keeping two
Lua versions around ugly.

* restrict myself to Clean Lua. If the checklist is as small as you
listed, I suspect it won't be too much trouble. I'm still at a loss
myself on which way to proceed regarding the lack of module(), though.

"Switching" to Lua 5.2 and dropping Lua 5.1 support would alienate the
current userbase, so this is not an option for a good while. (And I
wonder how long.)

WRT the rockspec format, I believe rockspecs (all? most?) will load as
valid Lua 5.2 code, since I always pushed them to be written in a
declarative subset of Lua 5.1. This declarativeness, however, has not
been enforced in code: is it possible to write valid rockspecs that
evaluatue as valid Lua 5.1 code but is not valid Lua 5.2? (Keep in
mind rockspecs load with an empty environment.) I know the opposite to
be true (since nothing prevents a rockspec from containing control
flow instructions, so a rockspec loaded with Lua 5.2 could contain
"goto"), but I'd rather avoid having to write a parser of a Lua subset
just to enforce compatibility.

A Clean Lua lint-style verification tool would be a godsend.

-- Hisham
http://hisham.hm/ - http://luarocks.org/