Re: about the new version

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

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

>Great!  I only hope, that at that moment not everything is already
>set in stone ;)

Not everything :-)
The new API is unlikely to change, and so is the new VM.
However, the opcodes themselves may change, for instance.

>> We welcome user feadback. That's one of the reasons for this list!
>
>That sounds like an invitation.  Here I go *bg*

Yes, it was an invitation. Your comments are welcome.
But just keep in mind the Lua is not designed in the list :-)

>But to have two different kind of "repeat" statements makes it harder.

You have a point.
However, "while 1 do" is not easy to optimize away, for technical reasons.
We replaced an optimization of "repeat ... until 1" with "repeat .. end"
because it made the code generation simpler.

>My suggestion: "break [<level>]"  where <level> is a number > 0 with
>a default of 1.

This makes it very error prone to put a new loop around an existing loop,
because you have to correct all levels.

>Bad examples ;)  What you really want is:
>
>  local line
>  while line = read() do

Ooo, let's not get into that :-)

>How about something else?  Have an additional flag beside "marked", say
>"destroyed".  Then, in the collection phase just check this flag.  If not
>set, call the GC method and then set the flag.  If already set, remove the
>object immediately.  (The real implementation is a little bit more
>complicated...)

We discussed this alternative and decided againt it because it would double
the memory requirements of large programs (which are the ones that use GC),
as you mentioned.

>Maybe I've missed something but IMO this sounds much better then just removing
>the whole stuff *g*

The move was towards more safety of Lua programs. Programs that need fine
control of memory allocation should then write these critical routines in C,
where "everything" is allowed... In general, we feel that it should not be 
easy to mess Lua's environment from within Lua. Of course, in C you're your
own master and can do as you please...

>Wow, that's encouraging :)  So here's another wish: Upvalues should be
>allowed as l-values (ie %foo = %foo + 1).  That way you have "static locals"
>for each instance of a function.  Afaics it shouldn't be that hard to
>implement... (I'll try if the code comes out.)

This will not happen :-)
Upvalues are for writing closures (mostly). Functions that use upvalues may be
called after the "enclosing" function has already finished, and so the locals
are not longer alive.
You can simulate this by using tables as upvalues and modifying fields in
the tables. The table itself is constant, but its fields are writable.

>I would even drop the requirement for the '%'.  It makes the code ugly *g*
>(look at Perl!)

Matter of taste, really. I think that '%' marks the place of "constant" values
and so is useful. Not having some kind of mark could mislead people into
thinking that upvalues were writable. Yes, if they were, '%' could be dropped.

--lhf