Re: about the new version

[Edgar Toernig <froese@...>]

Hi,

> We will soon (by Easter?) release a new (alpha) version of Lua.

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

>> I was wondering if the new version still listen for users feadbacks.
>
> We welcome user feadback. That's one of the reasons for this list!

That sounds like an invitation.  Here I go *bg*

> - there is a new control structure "break", and "repeat" may finish with
> "end" for infinite loops. For instance
>
> [code samples] 
>
> Also, statements can have labels. A break without a label finishes the
> inner loop (while/repeat), and a break with a label breaks the
> corresponding statement. (This is similar to breaks in Ada and Java.)

"break" is something I really missed.  I can understand the implementation
of the "repeat end".  It's a short syntax and really easy to implement.
And a multi level break is something you really want.  But I have some
objections to these changes:

IMO, the design of programing languages should always consider code
readability as a major point.  At the moment Lua is pretty good in that
part.  But to have two different kind of "repeat" statements makes it
harder.  You have to search for the end of the block to see, what kind of
loop this is.  IMO, the "while 1 do ..." is more two write, but you
instantly see, it's an infinite loop.  (If you are concerned about the
speed: you said you'd have a peephole optimizer in the new version.
I'll volunteer to write an optimizer for that *g*) 

I always thought, the "repeat" keyword itself was chosen just for this
reason (readability).  "do <block> until <expr>" would have been as easy
to implement as "repeat <block> until <expr>".  And if the  "repeat" was
not chosen for readability but for more precise error detection, that will
break with "repeat <block> end", too.

For the same reason I object to labeled statements for the "break".
First you have to invent silly names for the labels (and normally
come up with something like l1, l2, l3 *g*).  Second, it blows up
the syntax (incl. the indentation) and the major and third point:
When you see a "break l1" you don't know what loop will be termi-
nated.  You have to search for the statement with that label.

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


>  local line
>  repeat
>    line = read()
>    if line==nil then break end
>    ...
>  end 
>
>  local n,v = nil
>  repeat
>    n,v = next(t, n)
>    if not n then break end
>    ...
>  end 

Bad examples ;)  What you really want is:

  local line
  while line = read() do
    ...
  end

  local n,v
  while n,v = next(t, n) do
    ...
  end

I know it's not that simple to implement but that the designers of
Lua chose "==" instead of "=" for comparisons let me think, that
this has already been in someone's mind ;-)


> - the structures of opcodes changed. Instead of a byte-oriented stream of
> byte-codes, with each instruction taking a variable number of bytes, now
> the opcode is an array of longs (4 bytes), with each instruction using one
> position. (You can change that to 2-byte instructions, using smaller limits
> for maximum number of local variables, etc.) That makes code generation
> more straightforward, allows peep-hole optimizations (for instance, i=i+1
> codes as one single instruction), and facilitates the implementation of new
> control structures. Also, now Lua uses real "jump code" for conditionals.

A bold move *g*.  I once implemented a "for" and a "break" statement.  The
"for" went pretty good, but the "break" was nearly impossible.  I already
came to the conclusion that only a fixed sized instruction stream (where
backpatching would not relocate some code) would make it reasonable.
But considering the changes I would have to do I removed the "break". *g*


> - the hash algorithm for tables was rewritten. The new algorithm is faster
> than the old one, uses less memory, and is more stable (that is, bad
> cases are rarer).

If someone still works on this he should consider a minor problem of
tables in the current implementation:  keys whose data was set to nil
will not be garbage collected until the table is rehashed.  This can
lead to memory leaks under some circumstances.

> - we removed the garbage collection tag method for tables. That was a
> source of problems, because when there was no more references to a table we
> had to create one for the tag method. Garbage collection should be
> invisible from Lua. Now there is only GC tag methods for userdata (C data),
> and only C code can set them. (That is, GC tag methods concerns only C code.)

:-(  Ok, I know that the GC callback was kind of fragile (creating new
references to GC'ed objects will blow up the system).  But completely
removing this feature from Lua is IMO an unlucky shot.  Now you have
to worry about all garbage collection in C code where sometimes it's
much easier to do in Lua itself.  I prefer the way to make only as
much as necessary/reasonable in the boot language and the rest in
the language itself.  And, why should garbage collection be invisible?
The GC method is a destructor, a concept found in a lot of languages.

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

This way, the objects stay alive during the GC method and will be removed
on the next GC pass unless the callback has generated new references.
The drawback: objects with GC methods require two GC passes to be really
removed.

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


> - the nil in next/nextvar is optional ;-)

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

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


Ciao, ET.


PS:  Why don't you make some development snapshot releases so that people
like me can try out some of their ideas?  It's much easier to argument
with some code already at hand *g*