Re: about the next version

[jim@...]

Does this mean the next version is 5.0, not 4.1? sounds more
like a new version than an upgrade. I know you hate this but
I have to ask - what's the ETA on this release? spring/summer/fall?

Regards,
Jim


----- Original Message ----- 
From: "Roberto Ierusalimschy" <rieru@delirius.cs.uiuc.edu>
To: "Multiple recipients of list" <lua-l@tecgraf.puc-rio.br>
Sent: Tuesday, December 18, 2001 9:33 AM
Subject: about the next version


| 
| We are still a long way to a new official Lua version. But there are
| already some changes that we have implemented, and that probably will
| be present in the next version. Here is a short description of these
| changes.
| 
| 
| - Booleans: we have implemented a boolean type in Lua. Now, both false
| and nil test as "false", everything else test as "true". "not" always
| returns a boolean, but "a and b" and "a or b" always return "a" or "b"
| (the first that defines the result). Particularly, we have
| 
|   nil and x == nil
|   false and x == false
|   false or nil == nil
|   nil or false == false
|   not nil == true
|   not not nil == false
| 
|   Compatibility problems:
|     - true and false are reserved words.
|     - some dubious constructions can stop working, such as tests "x == nil"
|     where you really meant "not x", or "x ~= nil" where you really
|     meant "x". (You can start correcting your programs now ;-)
| 
| 
| - tag methods in tables: all tag methods are now stored in regular
| tables (as in Sol). Therefore, functions "gettagmethod", "settagmethod",
| etc. are deprecated. Tags are also deprecated. Tables and userdata have
| a "handler-table" (is this a good name?) where they store their tag
| methods. We did not change the semantics of ":" (but see below).
| 
|   Compatibility problems:
|     - we will build a compatibility library that emulates the old tag system
|     using "handler-tables". This library will be compatible with 4.0, not
|     with 4.1 alpha. (It is not difficult to build a compatibility library
|     for 4.1 alpha, I guess.) We expect that this library will give a good
|     level of compatibility (besides some points discussed below.)
| 
|     - userdata won't be collected by the order of their tags (as there is
|     no more tags). Instead, they will be collected in reverse order of
|     their creation.
| 
| 
| - no more Setglobal/getglobal tag methods: instead, access to global
| variables uses "regular" gettable/settable over the global table.
| 
| - no more tag methods for basic types: only tables and userdata can have
| a "handler-table". Moreover, "basic" tables and userdata (that is, those that
| you did not set a handler-table) cannot have tag methods, either.
| 
| - "easy inheritance": the tag methods for "gettable", "settable", and
| "index" can be a table, instead of a function. In that case, to "call"
| the tag method means to index that table. So, for A to inherit from B, we
| just set the "index" field in its handler-table to B; for instance
| 
|       metatable(A, {index=B})
| 
| 
| - lexical scoping: (this was already discussed, and is in the work version)
| 
|   Compatibility problems:
|     - upvalues in Lua are deprecated. You can prepare your programs by
|     making sure all upvalues you use are constant local variables. A simple
|     and always correct way to do that is to introduce an extra variable for
|     each upvalue:
| 
|     old:   function () ... %x ... end
|     new:   local _x = x; function () ... %_x ... end
| 
|     This does not change the meaning of your program in Lua 4.0, and will
|     keep that meaning in the new version. (Either you just remove all '%',
|     or you can use a compile-time option for Lua to ignore those '%'.)
| 
| 
| - upvalues in C does not come in the stack: (this was already discussed,
| and is in the work version). There is both a compile-time option for Lua
| to pass upvalues in the "old" way, and a function that pushes
| all upvalues in the stack (so you can call it in the beginning of your
| function to get the upvalues in the old way).
| 
| 
| - yield: maybe this co-routine facility will make it to the next version,
| but there are still many details to be checked.
| 
| - we are also thinking about block comments (maybe the --[[...]]) and
| some kind of optional declaration of globals, but there is nothing decided
| yet.
| 
| -- Roberto
| 
| 
| 
|