Clean Lua

classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Clean Lua

Dirk Laurie-2
2011/11/18 Francesco Abbate <[hidden email]>:

>
> 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.

Dirk

Reply | Threaded
Open this post in threaded view
|

Re: Clean Lua

Francesco Abbate
2011/11/18 Dirk Laurie <[hidden email]>:

> 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.

Hi Dirk,

I understand you point but in this does not invalidate my remarks, you
are just saying the you can cope with Lua 5.2. Of course you can, Lua
5.2 is still a very neat programming language but my point was that
you break compatibility the hard way for little or no gain at all.

Many people was using getfenv/setfenv regularly and this will not work
anymore. Also on the C side this will heavily affect programmers since
that feature was routinely used and isn't anymore available.

You should also think about LuaJIT2 since now many Lua users use
LuaJIT now and it seems that switch to 5.2 will be a good amount of
work for a lot of people without any clear gain.

Your argument about "the clean subset" is especially true for
languages like Javascript and for C++. The fact that a clean subset
exists it doesn't mean that you can change the language without any
concern about compatibility.

My point is that in some case you can break compatibility but it is
reasonable to do so only when you have important advantages by making
the changes.

--
Francesco

Reply | Threaded
Open this post in threaded view
|

Re: Clean Lua

Paul Hudson-2

On 18 November 2011 13:51, Francesco Abbate <[hidden email]> wrote:
t doesn't mean that you can change the language without any
concern about compatibility.

It's not reasonable to say that Luiz and Roberto made their decision "without any concern about compatibility". They were clearly concerned but decided to do what they did because to them they felt it the correct decision - for their own reasons, which have been explained here at length and I, at least, see no benefit in re-hashing them again. And it's their decision to make.

All that can be said is that you might have made a different decision.

Paul
Reply | Threaded
Open this post in threaded view
|

Re: Clean Lua

Patrick Donnelly
On Fri, Nov 18, 2011 at 9:05 AM, Paul Hudson <[hidden email]> wrote:

>
> On 18 November 2011 13:51, Francesco Abbate <[hidden email]> wrote:
>>
>> t doesn't mean that you can change the language without any
>> concern about compatibility.
>
> It's not reasonable to say that Luiz and Roberto made their decision
> "without any concern about compatibility". They were clearly concerned but
> decided to do what they did because to them they felt it the correct
> decision - for their own reasons, which have been explained here at length
> and I, at least, see no benefit in re-hashing them again. And it's their
> decision to make.

[I speak as an observer based on my experiences reading this list and
my limited interactions with the authors of Lua.]

People keep bringing up compatibility but the fact of the matter is
the authors encourage you to keep X version of Lua for your project as
long as your project exists. There is never a push to have you update
Lua alongside your application.

Lua evolves in necessary ways and doesn't keep parts that do not make
sense. While there is a "compatibility" consideration insofar that the
authors want to make simple *where possible* to translate Lua code
written in an older version of Lua to a new version, it is not central
consideration when making design decisions. This is a liberating mind
set when designing the language and allows them to "do it right" the
second time if they couldn't do it the first time.

To think of Lua as a specification for a programming language which
doesn't change is simply wrong.

--
- Patrick Donnelly

Reply | Threaded
Open this post in threaded view
|

Re: Clean Lua

GrayFace
In reply to this post by Dirk Laurie-2
On 18.11.2011 20:27, Dirk Laurie wrote:
> 2. Don't use # or the table library on non-sequences.

WOW, why is that?


What I don't like about 5.2 is that 5.1 is cleaner in many ways. __gc
behaves as a normal methamethod (no 'tagging' of userdata), function
definitions always produce a new function, 'level' parameter of 'error'
actually makes sense (it lost any sense in 5.2 due to pointless decision
to abolish tail calls counting).
5.2 has cleaner sides too, like yielding despite
pcall/iterator/metamethod and _ENV.


--
Best regards,
Sergey Rozhenko                 mailto:[hidden email]



Reply | Threaded
Open this post in threaded view
|

Re: Clean Lua

Hisham Muhammad
In reply to this post by Dirk Laurie-2
On Fri, Nov 18, 2011 at 11:27 AM, Dirk Laurie <[hidden email]> wrote:

>
> 2011/11/18 Francesco Abbate <[hidden email]>:
> >
> > 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/

Reply | Threaded
Open this post in threaded view
|

Re: Clean Lua

Dimiter 'malkia' Stanev
In reply to this post by Dirk Laurie-2
What is the purpose of this?

With other languages, there are many different implementations, and even
compilers from the same vendors differ, as "C" exposes the machine bits
up-front.

So it makes sense to have "clean" C there, as in - use only things that
would for sure compile on most of the "C" compilers out there...

But why for lua?



On 11/18/11 5:27 AM, Dirk Laurie wrote:

> 2011/11/18 Francesco Abbate<[hidden email]>:
>>
>> 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.
>
> Dirk
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Clean Lua

Roberto Ierusalimschy
In reply to this post by Hisham Muhammad
> 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...

The list of incompatibilites from 5.1 to 5.2 is in the reference manual
(currently at http://www.lua.org/work/doc/manual.html#8).

Moreover, keep in mind that for Lua compiled with LUA_COMPAT_ALL on,
most of these differences vanish. (LUA_COMPAT_ALL is on in the default
makefile.) As I already pointed out, I think most of the work to migrate
from 5.1 to 5.2 will be to elliminate deprecated features from 5.0
which are not supported anymore in 5.2. (Such changes naturally lead to
"Clean" code.)

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Clean Lua

Petite Abeille
In reply to this post by Dirk Laurie-2

On Nov 18, 2011, at 2:27 PM, Dirk Laurie wrote:

> 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.

6. Always require module explicitly
7. Don't use (set|get)fenv.
8. Don't use _ENV
9. Don't yield across language boundary
10. Don't use the new meta methods

Other random stuff from the release notes:

        • Function module is deprecated. Modules are not expected to set global variables anymore, and it is easy to set up a module with regular Lua code.
        • Functions setfenv and getfenv are deprecated, because of the changes in environments.
        • Function math.log10 is deprecated. Use math.log with 10 as its second argument, instead.
        • Function loadstring is deprecated. Use load instead; it now accepts string arguments and are exactly equivalent to loadstring.
        • Function table.maxn is deprecated. Write it in Lua if you really need it.
        • Function os.execute now returns true when command terminates successfully and nil plus error information otherwise.
        • Function unpack was moved into the table library and therefore must be called as table.unpack.
        • Character class %z in patterns is deprecated, as now patterns may contain '\0' as a regular character.
        • The table package.loaders was renamed package.searchers.
        • Lua does not have bytecode verification anymore. So, all functions that load code (load and loadfile) are potentially insecure when loading untrusted binary data. (Actually, those functions were already insecure because of bugs in the verification algorithm.) When in doubt, use the mode argument in function load to restrict it to loading textual chunks.

http://www.lua.org/work/doc/#changes

And some more:
http://www.lua.org/work/doc/manual.html#8


There was also a nice blog post a while back highlighting many of the changes between 5.1 and 5.2. Cannot find a link though :/

Ah, yes, here you go:

http://www.corsix.org/content/look-lua-52-work3

In short, good luck! :)


Reply | Threaded
Open this post in threaded view
|

Re: Clean Lua

Petite Abeille
In reply to this post by GrayFace

On Nov 18, 2011, at 5:41 PM, GrayFace wrote:

>> 2. Don't use # or the table library on non-sequences.
>
> WOW, why is that?

The perennial "list with holes" conundrum.


Reply | Threaded
Open this post in threaded view
|

Re: Clean Lua

William C. Bubel
In reply to this post by GrayFace
On 11/18/2011 11:41 AM, GrayFace wrote:
> What I don't like about 5.2 is that 5.1 is cleaner in many ways.
> ...
> function definitions always produce a new function

Can somebody clarify this for me? What's the situation in 5.2 where the
function keyword wouldn't produce a function object?

Reply | Threaded
Open this post in threaded view
|

Re: Clean Lua

Ignacio Burgueño

On Fri, Nov 18, 2011 at 10:43 PM, William C. Bubel <[hidden email]> wrote:
On 11/18/2011 11:41 AM, GrayFace wrote:
> What I don't like about 5.2 is that 5.1 is cleaner in many ways.
> ...
> function definitions always produce a new function

Can somebody clarify this for me? What's the situation in 5.2 where the
function keyword wouldn't produce a function object?


function foo()

  local function bar()
  end

  print(bar)
end

foo()
foo()


In Lua 5.1, a call to function "foo" will create a new instance of function "bar" each time. Lua 5.2 will create only one instance if "bar" has the same upvalues each time.
Reply | Threaded
Open this post in threaded view
|

Re: Clean Lua

William C. Bubel
On 11/18/2011 08:45 PM, Ignacio Burgueño wrote:

>
> On Fri, Nov 18, 2011 at 10:43 PM, William C. Bubel <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     On 11/18/2011 11:41 AM, GrayFace wrote:
>     > What I don't like about 5.2 is that 5.1 is cleaner in many ways.
>     > ...
>     > function definitions always produce a new function
>
>     Can somebody clarify this for me? What's the situation in 5.2 where the
>     function keyword wouldn't produce a function object?
>
>
> function foo()
>
>   local function bar()
>   end
>
>   print(bar)
> end
>
> foo()
> foo()
>
>
> In Lua 5.1, a call to function "foo" will create a new instance of
> function "bar" each time. Lua 5.2 will create only one instance if "bar"
> has the same upvalues each time.

This seems like a reasonable optimization. Is there a hidden gotcha that
GrayFace is concerned with that I'm not seeing? I suppose if you were
doing equality checks between functions to determine object identity,
you would get tripped up, but I was under the impression that tables
were the golden standard for objects.

Reply | Threaded
Open this post in threaded view
|

Re: Clean Lua

David Manura
On Fri, Nov 18, 2011 at 9:01 PM, William C. Bubel <[hidden email]> wrote:
>>     On 11/18/2011 11:41 AM, GrayFace wrote:
>>     > What I don't like about 5.2 is that 5.1 is cleaner in many ways. ...
>>     > function definitions always produce a new function
> This seems like a reasonable optimization. Is there a hidden gotcha that
> GrayFace is concerned with that I'm not seeing? I suppose if you were
> doing equality checks between functions to determine object identity,
> you would get tripped up, but I was under the impression that tables
> were the golden standard for objects.

In one of my modules I was using `return function()end` to generate
new unique keys for a table.  I probably did that rather than `return
{}` because it takes a little less memory [1] and the value is more
opaque/immutable, not that it really mattered either way, but why not?
 That code failed in 5.2 testing though.  So I changed it to `local x;
return function() x=nil end` because I saw that on the list.  That's
less comprehensible.  Moreover, in retrospect, although it worked, I'm
not so sure it's even correct.  Although the implementation of Lua
5.2.0-beta does not presently optimize that by caching the closure,
the sections on this from the 5.2.0-beta manual suggest that
implementations might be allowed to:

  "[3.4.3 – Relational Operators] Closures with the same reference are
always equal. Closures with any detectable difference (different
behavior, different definition) are always different."
  "[Changes in the Language] Equality between function values has
changed. Now, a function definition may not create a new value; it may
reuse some previous value if there is no observable difference to the
new function."

I see no "detectable difference", so I infer that my code was wrong,
and thankfully so since writing `return {}` or `return newproxy()` is
more readable (or just using integer keys is the most efficient).
`newproxy()`, which has some slight advantages similar to
`function()end`, is not a standard function in 5.2.0-beta though, so
'{}' would probably be it.


One case I would want to optimize, but where the 5.2.0-beta
implementation does not (but according to the reference manual
apparently could) is where upvalues are constants:

  function f(n)
    local pi = 4  -- approximately
    local function area(r) return pi*r^2 end
    local function perimeter(r) return 2*pi*r end
    for i=1,n do print(area(i), perimeter(i)) end
  end

Another case is where an anonymous closure is immediately consumed by a call:

  local x = 0
  for i=1,1E+7 do
    x = x + (function() local y = i^2; return y/(y+1) end)()
  end
  print(x)

In that last example, it's not necessary safe to reuse the closure as
is, but it would seem valid for an implementation to optimize the code
by first automatically rewriting it as

  local x = 0
  for i=1,1E+7 do
    x = x + (function(i) local y = i^2; return y/(y+1) end)(i)
  end
  print(x)

which does permit reuse of the closure (and in 5.2.0beta is twice as fast).

So, the 5.2 semantics appear to permit greater room for optimization,
though the current standard implementation does not take full
advantage of it.

[1] http://www.wowwiki.com/Lua_object_memory_sizes

Reply | Threaded
Open this post in threaded view
|

Re: Clean Lua

steve donovan
In reply to this post by Roberto Ierusalimschy
On Fri, Nov 18, 2011 at 8:29 PM, Roberto Ierusalimschy
<[hidden email]> wrote:
> Moreover, keep in mind that for Lua compiled with LUA_COMPAT_ALL on,
> most of these differences vanish. (LUA_COMPAT_ALL is on in the default
> makefile.)

This is an important point; in particular, module() is going to be
available for a long time.

Old Lua 5.0-isms like local 'arg' are easy to fix and LuaJIT has been
useful in this respect.

There are some gotchas, for instance the return type of os.execute
changes. So my preferred approach has been to write compatibility
routines, and so far I've really had no problems writing Lua that
works with both versions.

In Penlight, the 5.1/5.2 compatibility functions are in pl.utils, lines 200-280

https://github.com/stevedonovan/Penlight/blob/master/lua/pl/utils.lua

There's a version of set/getfenv there as written by Sergey Rozhenko [1]

The approach to functions like load() and os.execute() that have
changed signatures is to define utils.load and utils.execute that
behave consistently.

Separating this code out as lua52-compat.lua would be straightforward.

steve d.

[1] http://lua-users.org/lists/lua-l/2010-06/msg00313.html

Reply | Threaded
Open this post in threaded view
|

Re: Clean Lua

Axel Kittenberger
In reply to this post by Dirk Laurie-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.

I don't get the discussion. We all should know by now, like Mike Pall*
said, 5.2 is going to be Vista of Lua. Enough breaks to an annoyance,
while there aren't much good stuff for the end user to compensate.
Anyway lets just get over it, and see what Luiz/Roberto come up with
for the "7" of Lua releases.

Otherweise I know you posted once you like this list, because you said
here are the people that just want to figure out how things work and
then loose interest (forget the abbreviation). Anyway, not everyone is
like that. I just like getting things done, and I don't see why a
discussion like this helps me getting anything done better. The other
observation I recently had on maillinglists, its usually not very
productive when the topic is about how others should code, since
everyone got his/her ideas, and feels offended by others saying they
aren't good. Yes, Maintainabilty should be a concern, but usually your
just yourself who gets to suffer if you dont do it well, so its an
lessons everyone learns soon enough anyway.

So can we just stop bickering about 5.2 and switch over to get some
cool stuff done?

* http://lua-list.2524044.n2.nabble.com/any-plan-about-luajit2-support-5-2-td5746709.html

Reply | Threaded
Open this post in threaded view
|

Re: Clean Lua

Dirk Laurie-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".

> I don't get the discussion.
The intended point is just the one sentence quoted above.

> …
> The other observation I recently had on maillinglists, its usually
> not very productive when the topic is about how others should code,
I was basically reporting on how I code.  I don't care about how others
code.

> …
> So can we just stop bickering about 5.2 and switch over to get some
> cool stuff done?
For the first few replies after I posted I was quite sorry I did, since
some people did "bicker about" 5.2 instead of helping to pin down
Clean Lua (which I actually thought was a cool idea, sorry you didn't
seem to like it much late on a Saturday night).

Then came some very enlightening posts by Petite Abeille, David
Manura and Steve Donovan.  I hope your reaction to my post did
not stop you from reading theirs.

Dirk

Reply | Threaded
Open this post in threaded view
|

Re: Clean Lua

Rena
On Sat, Nov 19, 2011 at 21:53, Dirk Laurie <[hidden email]> wrote:

>>> 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".
>
>> I don't get the discussion.
> The intended point is just the one sentence quoted above.
>
>> …
>> The other observation I recently had on maillinglists, its usually
>> not very productive when the topic is about how others should code,
> I was basically reporting on how I code.  I don't care about how others
> code.
>
>> …
>> So can we just stop bickering about 5.2 and switch over to get some
>> cool stuff done?
> For the first few replies after I posted I was quite sorry I did, since
> some people did "bicker about" 5.2 instead of helping to pin down
> Clean Lua (which I actually thought was a cool idea, sorry you didn't
> seem to like it much late on a Saturday night).
>
> Then came some very enlightening posts by Petite Abeille, David
> Manura and Steve Donovan.  I hope your reaction to my post did
> not stop you from reading theirs.
>
> Dirk
>

I don't understand the purpose of "Clean Lua". With C, there are a lot
of things you can't rely on - compiler/preprocessor features/bugs that
may or may not be present, language extensions, the presence of header
files and libraries, etc. There can be a lot of differences between C
as interpreted by one platform and C on another. This IMO is one of
C's biggest weaknesses, and the point of "Clean C" is to avoid as much
of those uncertainties as possible, so as to ensure your code compiles
on as many platforms as possible.

Lua doesn't have this issue. For the most part, Lua here is Lua there,
and if you are dealing with a platform that has some incompatible
changes, it's probably different enough that your code would already
need some major changes anyway. The only difference most people will
have to worry about is Lua 5.1 vs Lua 5.2 vs LuaJIT, which are all
extremely similar.

To me it seems like "Clean Lua" means "Lua [5.1|5.2|JIT] with a couple
of wrappers to emulate some [5.1|5.2|JIT] behaviours if desired,
without relying on features specific to one of the three". Don't rely
on __gc for tables or any LuaJIT extensions and know how to use both
setfenv() and _ENV, and you're fine.

Plus, like others have mentioned, it's not as important to be
compatible with multiple versions, since you can have several versions
installed, or if embedding Lua in a program, you can keep that program
at whatever version you please.

--
Sent from my toaster.

Reply | Threaded
Open this post in threaded view
|

Re: Clean Lua

Francesco Abbate
In reply to this post by Dirk Laurie-2
2011/11/20 Dirk Laurie <[hidden email]>:
> For the first few replies after I posted I was quite sorry I did, since
> some people did "bicker about" 5.2 instead of helping to pin down
> Clean Lua (which I actually thought was a cool idea, sorry you didn't
> seem to like it much late on a Saturday night).
>
> Then came some very enlightening posts by Petite Abeille, David
> Manura and Steve Donovan.  I hope your reaction to my post did
> not stop you from reading theirs.

I'm personally not interested to "clean Lua" because the fact itself
that we need a clean subset of Language means that the language is
"wrong" in some aspects.

This is especially true for Javascript for example, which is known to
have many "wrong" features. For Javascript it is therefore quite
compelling to choose a subset of the language and some good practices
(See "Douglas Crockford, "Javascript: the good part").

Since I like a lot the Lua programming language I would like to have
it right, I don't want a bad programming language to choose a clean
subset. I consider that Lua 5.1 is already an excellent programming
language and I was therefore expressing my concerning about changes
introduced with Lua 5.2.

Please note that to design the programming language "right" is
absolutely crtitical for being successfull. I believe that Python is
an excellent example where they have made a lot of "right" design
decisions to shape an excellent and successfull programming language.

Lua is also another example of right design decisions that made a
successfull programming language. The difference with Python was that
Lua focused on being small, fast and with a clean design.

Note also that if it was possible for Lua to have an outstanding JIT
compiler it was because the programming language itself has a very
good and clean design.

If you say: "I don't care about how Lua changes because I can choose a
clean subset" this means that you don't understand the stake. Python
understood this point so well that they thoroughly discuss each
language enhancement proposal (PEP) in an open discussion.

I know that for Lua the decisions are taken by Roberto and Luiz and
they have the right of doing so but I have the right to express my
point of view.

Francesco

Reply | Threaded
Open this post in threaded view
|

Re: Clean Lua

Michael Richter
Is there any way we can tag posts with "Flogging Dead Lua 5.2 Horses" tags so I can read actual content instead of people whining over decisions made and completed?

--
"Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot."
--Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
12