RE: about the new version

[Jim Mathies <Jim@...>]

wow.  

-----Original Message-----
From: Roberto Ierusalimschy [mailto:roberto@inf.puc-rio.br]
Sent: Friday, April 07, 2000 11:35 AM
To: Multiple recipients of list
Subject: about the new version


We will soon (by Easter?) release a new (alpha) version of Lua.
The big change is that Lua now is completely reentrant. The state is 
passed around as an extra parameter, so that there are no global
variables 
in the code. (There is a mechanism with #defines that should ensure that

old code compiles without changes.) 

To make that change, we have to touch the whole code; therefore, we took

the opportunity to improve some algorithms, and to remove some "bad" 
features. In the end, the new version is more than 20% faster than Lua
3.2,
often much more than that. (E.g., the life program, from Dave Bollinger,

runs in less than 50% of the previous time). 

The other main changes are listed below: 

- in a call like f(g(x)), all results from `g' are passed to `f', when
`f' 
is the last/only argument. (This may result in incompatibilities; for 
instance, "write(gsub(...))" will write an extra number, which is the 
second result from gsub. You may correct this case with
  "write(gsub(...), '')", or "local g=gsub(...); write(g)".) 

- there is a new control structure "break", and "repeat" may finish with

"end" for infinite loops. For instance 

  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 

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

- the code now uses "const" consistently. Among other things, that makes
it 
clear that the only global names in the C code are "const", and makes
the 
API more precise. (This will also generate some warnings in old code, 
because lua_getstring now returns a "const char *").

- the code now is "pure C": ANSI C *and* C++. So you can compile Lua as
a 
C++ program without errors or warnings. (With our compiler [gcc
2.7.2.3], 
this results in a much bigger and a little slower program; but you have
the 
choice). 

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

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

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

- we removed "read patterns" from the "read" function. Nobody (or very
few 
people) used them, and they were very inefficient. Now the only options
are 
"*a" (read the whole file), "*l" (read a line, the default), "*n" (read
a 
number), and "*w" (read a word). These options were already present in 
Lua3.2, but now they are much faster. (The old read patterns can still
be 
enabled with a #define). 

- the optimizations during code generation can change tests such as
"a<b" 
(e.g., "if a<b then..." will generate "jump if a>=b"). Therefore, there
is 
no point in having four different tag methods for comparisons, when we 
cannot know which one will be used. Now, there is only one tag method
for 
comparison ("lt", less than). Other tests use this tag method following
the 
usual rules: a>b === b<a; a<=b === not (b<a); b<=a === not (a<b). 

- the whole debug API was rewritten. The old API used too many pointers
to 
variables, and has too many special cases and codes. It should be easy
to 
change programs to this new API, and we will provide an "adaptor" that 
simulates the old API using the new one. 

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


-- Roberto