Re: upgrading to 4.0(a)

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

>From: Stephan Herrmann <stephan@cs.tu-berlin.de>
>
>Finally, I made it to upgrade to Lua4.0(alpha).
>Here are my (unpleasant) findings, some of which concern the
>list of incompatibilities, but there is also one severe bug.
>
> * 'gc' tagmethod not settable from Lua

'gc' tagmethods written in Lua open the way to subtle bugs.
Ditto for 'gc' tagmethods for tables.
So, we have restricted gc' tagmethods to userdata; and these can only be set
in C, because typically all you want to do is free() those pointers.
Moreover, gc' tagmethods for userdata are now called in decreasing order of
tags, so that you can free structures in the reverse order they were
created (in X11, for instance, you have to close a window before closing
the display).
 
> * somewhere I learned, that type() returns two values: type and tag.
>   Although it was undocumented, it is a feature that disappeared.

Two reasons: the tag is already returned by tag() and also it could give
unexpected results when passing type() to another function, because
multiple results are now passed along, ie f(type()) would receive 2 arguments.

Likewise, setglobal no longer returns a value.

>   And its disappearance produces errors that are not at all obvious.

Yes, I'm sorry.

> * lua_seterrormethod disappeared. (Why?)

To make it clear that the way to do it is to set _ALERT or _ERRORMESSAGE.

> * lua_State argument needed also in non-reentrant programs for luaL_verror()

The API in 4.0b will different from 4.0a there wil no single-state version.

> * how about a little guide on adapting custom made main-programs?
>	(creating the lua_State, using begin/endblock() for opening libs..)

Good suggestion.  We'll have to write this.

> * below is a program that screws up the internal Lua-Stack. Doesn't look
>   really dangerous, does it?

This was a bug in 4.0a. It has been corrected in 4.0b.

Thanks for the comments.

>I'm the only one who needs this predictable ordering?

Surely not. But I don't see a way out.
Perhaps you can give more examples of why this would be useful and how this
could be implemented...

>BTW: what is a tag, that is guaranteed to be invalid? -2 ?

Yes. Perhaps we should add LUA_NOTAG, like we already have LUA_NOREF.
--lhf