Lua 4.0

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

Lua 4.0

Roberto Ierusalimschy
About Lua 4.0:

The good news is that we are finishing the last modifications to release a 
beta version. The bad news is that those are somewhat big modifications ;-) 
Mainly, we are redesigning the C API (more about that later). 

Although we will release the next version as beta, we intend it to be as 
final as possible. But as there are many changes, we prefer to call it 
beta, and wait a little longer before releasing a final version. But we 
promise not to change any visible part of Lua from the beta version to the 
final 4.0 version, unless someone finds something very weird. 

We hope to release Lua 4.0 beta by mid-September.


The news in the new version are:

- new API: (much) simpler, smaller, and (a little) faster.
  (more about that later ;-):

- table of globals: all globals are now stored in a regular table; you can
change that table, so that you change all globals with a single (and fast)
operation.

- `for' statement for tables: «for k,v in t do ... end»

- no more '$debug': full speed *and* full debug information.
  (Actually, no more pragmas at all.)

- improved error messages; examples:

  > foo()
  error: attempt to call global `foo' (a nil value)

  > local a; print(a..1)
  error: attempt to concat local `a' (a nil value)

- improved support for 16-bit machines (we hope)
- improved treatment for memory allocation errors
- non-recursive garbage-collector algorithm


About the new API: the current API between Lua and C is quite simple for 
simple things, but too much complex for non-trivial tasks. For instance, 
very few people really understands why/when/how to use beginblock/endblock. 
So, we are replacing the current design (with two structures lua2C/C2lua) 
by a simpler one with only one stack. We get rid of beginblock/endblock, 
lua_Object, and getparam/getresult. All objects are created on the top of 
the stack. lua_is* and other queries have direct access to any element on 
the stack. When a C function is called, its parameters are on the stack. 
When it returns, the results are also on the stack. To separate them, the 
function returns (in C) the number of results it is returning (in Lua). The 
auxlib remains mainly unchanged, so for many simple functions the only 
change is this "return int". For instance, the `sin' function in mathlib 
now will be 

  static int math_sin (lua_State *L) {
    lua_pushnumber(L, sin(TORAD(luaL_check_number(L, 1))));
    return 1;  /* <<<< Tells Lua it is returning one result */
  }

As we said, this new API is much simpler to explain, it is much easier to
implement, and it is faster and smaller. Although it is not difficult
to change (by hand) a program with the old API to the new one, we are
afraid we won't be able to provide a "compatibility module" that simulates
the old API over the new one.

We feel that most C libraries are either small or are generated 
automatically with tools like SWIGLua and tolua. We intend to update tolua 
as soon as possible to generate code for 4.0, and we are willing to help 
the writers of others tools to adapt their code, if necessary. 

-- Roberto

Reply | Threaded
Open this post in threaded view
|

RE: Lua 4.0

Ashley Fryer-2
>When a C function is called, its parameters are on the stack.
>When it returns, the results are also on the stack. To separate them, the
>function returns (in C) the number of results it is returning (in
>Lua).

Why is it necessary for the C API to return the number of results it pushed
onto the stack?  Wouldn?t it would be simpler and less error-prone for Lua
to infer that information directly from the stack?

IE, why can?t your example:

static int math_sin (lua_State *L) {
  lua_pushnumber(L, sin(TORAD(luaL_check_number(L, 1))));
  return 1;  /* <<<< Tells Lua it is returning one result */
}

be written as:

static void math_sin (lua_State *L) {
  lua_pushnumber(L, sin(TORAD(luaL_check_number(L, 1))));
}

It should be trivial for Lua to track the number of results pushed by the
API, yes?

ashley



Reply | Threaded
Open this post in threaded view
|

Re: Lua 4.0

Christian Vogler-2
In reply to this post by Roberto Ierusalimschy
On Fri, Aug 25, 2000 at 06:10:14PM -0300, Roberto Ierusalimschy wrote:
> We hope to release Lua 4.0 beta by mid-September.

Cool!

> - `for' statement for tables: «for k,v in t do ... end»

Forgive me if this topic has already been beaten to death, but what is
the advantage of this new syntax over the old foreach, such as:

foreach(t, function(k,v) ... end)

?

I suppose it eliminates the need to refer to upvalues with the "%"
syntax, but what else?

- Christian

Reply | Threaded
Open this post in threaded view
|

Re: Lua 4.0

Erik Hougaard
In reply to this post by Ashley Fryer-2
----- Original Message -----
>Why is it necessary for the C API to return the number of results it pushed
>onto the stack?  Wouldn't it would be simpler and less error-prone for Lua
>to infer that information directly from the stack?

Cause that would prevent using the stack during your api function.. And
since the is no more begin/end block it would be impossible to push stuff on
the stack to perform table functions ect....

/Erik



Reply | Threaded
Open this post in threaded view
|

Re: Lua 4.0

Luiz Henrique de Figueiredo
In reply to this post by Roberto Ierusalimschy
>> - `for' statement for tables: «for k,v in t do ... end»
>
>Forgive me if this topic has already been beaten to death, but what is
>the advantage of this new syntax over the old foreach, such as:
>
>foreach(t, function(k,v) ... end)
>
>I suppose it eliminates the need to refer to upvalues with the "%"
>syntax, but what else?

Right, it avoids upvalues. And it also avoids the cost of a function call
per each element in the table.
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: Lua 4.0

Christian Vogler-2
On Sat, Aug 26, 2000 at 10:47:08AM -0300, Luiz Henrique de Figueiredo wrote:
> Right, it avoids upvalues. And it also avoids the cost of a function call
> per each element in the table.

That makes sense to me. By the way, in lua 3.2 lua_dostring() takes a
char * instead of a const char *. This necessitates some ugly casts in
the client code. Will this be fixed in lua 4.0?

- Christian

Reply | Threaded
Open this post in threaded view
|

Re: Lua 4.0

Christian Vogler-2
In reply to this post by Roberto Ierusalimschy
On Sat, Aug 26, 2000 at 04:10:11PM -0300, Luiz Henrique de Figueiredo wrote:
> All strings in the C API have been changed to const char * in 4.0.
> See 4.0 alpha for a try run.
> 
> I guess the casts you mention are only necessary in C++, but Lua has a C API.
> :-)

Thanks. Actually, they're necessary in 100% portable ANSI C, too.

> "I use Lua because I like the language more than C++."
> -- Paul Bleisch, in rec.games.programmer.
> 
> (I'm sorry, I don't mean to star a flame war.)

Well, I'd use something else than C++, too, if there were a good
cross-platform alternative for high-performance numeric projects.

- Christian

Reply | Threaded
Open this post in threaded view
|

new lua stack ( was: RE: Lua 4.0 )

Ashley Fryer-2
In reply to this post by Erik Hougaard
>>Why is it necessary for the C API to return the number of results
>it pushed
>>onto the stack?  Wouldn't it would be simpler and less error-prone for Lua
>>to infer that information directly from the stack?
>
>Cause that would prevent using the stack during your api function.. And
>since the is no more begin/end block it would be impossible to
>push stuff on
>the stack to perform table functions ect....

It seems that this is only an issue if you use the stack and then don't
clean-up after yourself.  IE if you push something "temporary" onto the
stack, and then leave it there permanently.

Table functions should not be a problem because they pop from the stack any
values they use.  Nothing is left on the stack after the call.

The only problem case I can think of is where one Lua/C API reentrantly
calls another Lua function which returns values on the stack.  The outer
Lua/C API would then need to clean-up the stack, popping those values from
the inner API call before returning its own (unless it actually wanted to
return those values).

Is there something else I'm missing, because if this really is the only
reason for the new syntax, wouldn't it be better to shift the burden to the
less-frequent special case instead of requiring every API go through this
error-prone procedure?

ashley



Reply | Threaded
Open this post in threaded view
|

RE: Lua 4.0

Andy Tai
In reply to this post by Roberto Ierusalimschy
It would rather be difficult to start a flame war over this.  It is like
saying "I use OpenGL because I like it more than Postscript, which cannot do
3D!"


-----Original Message-----
From: Luiz Henrique de Figueiredo [[hidden email]]
Subject: Re: Lua 4.0


I can't resist a quote from our quotes page:

"I use Lua because I like the language more than C++."
-- Paul Bleisch, in rec.games.programmer.

(I'm sorry, I don't mean to star a flame war.)
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: new lua stack ( was: RE: Lua 4.0 )

Roberto Ierusalimschy
In reply to this post by Ashley Fryer-2
Suppose you want a function that returns 10 indices from a table stored in 
a global 't'. The main point is: you don't want to do getglobal ten times. 
You want to do it once, and keep that temporary value in the stack *while* 
you access the ten elements. (The stack in the API allows you to access 
elements inside it; only modifications follow a strick stack disciplinne.) 
When you finish, the table is still in the stack, *below* the ten values 
you want to return. Then you either need extra stack-manipulation functions 
(such as rotate) to remove the extra element, or you simply say "return 
10". 

This is not a special case. There are many other cases where you must
keep intermediate values while you compute the final results, and those
intermediate values will always be below the final results.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Re: Lua 4.0

Martin Doerin
In reply to this post by Andy Tai
>Thanks. Actually, they're necessary in 100% portable ANSI C, too.

And I hope it will stay 100% ANSI C. 

Especially for all the GUI toolkits it's true, that with the introduction 
of C++ portability mostly means the portability of the g++ compiler. 
People get confused with Templates/Exceptions/.. or not. It's not, that 
the OO features would be bad, but there is much complex stuff apart from 
that.

--------------------------------------------------------------------------------------------------------
Martin Döring, Systemtechnik (IDT)
MAN Nutzfahrzeuge AG
Dachauerstraße 667
D-80995 München

Tel.:   +49(0)89 / 1580 - 1199
Fax:   +49(0)89 / 1580 - 91-1199
E-Mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

RE: Lua 4.0

Paul Bleisch-3
In reply to this post by Roberto Ierusalimschy
Just to clarify this quote a little more.  I remember making
the quote, just not when...

I do still use Lua (it is central to our real-time cinematics
system here) and I still prefer Lua to C++ in general.  I pretty 
much prefer anything (including ANSI C when possible) to C++.  
Unfortunately, as others have mentioned, one still finds cases 
where C++ is the most non-square peg for a round hole.  

Has Luiz has said, no flame wars please.

Paul



> -----Original Message-----
> From: Luiz Henrique de Figueiredo [[hidden email]]
> Sent: Saturday, August 26, 2000 2:10 PM
> To: Multiple recipients of list
> Subject: Re: Lua 4.0
> 
> 
> >By the way, in lua 3.2 lua_dostring() takes a
> >char * instead of a const char *. This necessitates some 
> ugly casts in
> >the client code. Will this be fixed in lua 4.0?
> 
> All strings in the C API have been changed to const char * in 4.0.
> See 4.0 alpha for a try run.
> 
> I guess the casts you mention are only necessary in C++, but 
> Lua has a C API.
> :-)
> 
> I can't resist a quote from our quotes page:
> 
> "I use Lua because I like the language more than C++."
> -- Paul Bleisch, in rec.games.programmer.
> 
> (I'm sorry, I don't mean to star a flame war.)
> --lhf
>