Re: about the new version

[Luiz Henrique de Figueiredo <lhf@...>]

>From: Edgar Toernig <froese@gmx.de>

>You've got a really bad peephole optimizer if it can't reduce the
>"while 1 do" ;)

We'll look into this again. Maybe it can be done after all.
Like I said, there were technical reasons for this.

>A "break [<label>]" sounds more like a "goto" in disguise ;).

Which it is, of course. Only it's a kind of 'polite' goto, as are while and
repeat.

>> The move was towards more safety of Lua programs.
>
>Yeah, castration is pretty safe *g*

Ok, but we really think that it is important for an embedded language to be
as safe as possible; in particular, it should not be easy or even possible to
crash a host program from within Lua.

>> Programs that need fine control of memory allocation should then write these
>> critical routines in C,
>
>It's not about fine control of memory allocation but about destructors for
>structures created within Lua.

But these only have to set GC tag methods for user data, because these
are C structures, right? Exactly my point: if C allocates something, then yes
it should be notified when this something is no longer used in Lua, so that
it can be freed in C. This was (and is) the main motivation for having GC
tag methods. The move is simply to constrain that these GC tag methods can only
be written in C and only for user data. How would GC tag methods in Lua free
anything?

>Maybe I worded it wrong.  I don't want to change the local of the upper function
>but the upvalue itself (in Closure.consts[]).

Ah, this is indeed different. Sorry if I misunderstood you.
I think one way to do this is to use higher-order functions, ie functions that
return closures. Different closures of the same function share the memory for
the function and so are not space-inefficient.

Yes, having upvalues writable in the sense you mentioned would be possible,
but I'd still stick to the '%' marker so that it is clear that %x does not
refer to the 'x' that lives in the outer scope. This marker would be even
more important in this case.

Anyway, I think that having tables as upvalues is a simple solution that
(almost) does what you want and works already.

>Something else:  I realize - and accept - that backward compatibility is your
>main design criteria.

Backward compatibility is now a must, if we want Lua to be used widely.
A moving target does not live long, specially if it is a language.
But I wouldn't say that backward compatibility is our main design criteria.
Our main design criteria remain: simplicity, efficiency, portability, and
low embedding cost, as stated in the our site.

Sometimes, we have to break backward compatibility: some of the changes we
are proposing for the new version do this; the 'break' statement, for instance
(no pun intended). The introduction of a new keyword potentially breaks old
code (oh, that pun again!). The new API is also a major change (but we hope
that there are no incompatibilities here).
We did introduce incompatibilities before; for instance when we introduced
anonymous function we restriced the kind of expressions that could appear
in a function L(...)  statement.

Bottom line: we are committed to backward compatibility but only as far as
we can keep our primary goals: simplicity, efficiency, portability, and ease
of embedding.

>I guess that even you sometime wish that you could break compatibility.

Oh, sure. The ';' issue is a pain, for instance.

Thanks a lot for your insightful suggestions. Be assured that we are listening.
--lhf