lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On Sat, Sep 24, 2011 at 8:27 AM, Dirk Laurie <dpl@sun.ac.za> wrote:
> A recurrent theme on this list is wishful thinking about what might
> be in the next Lua,

Well, we haven't had that one for a while, so here are some ideas,
based on the observed trajectory so far.

There has been a tendency for global functions to get wrapped in
tables, and then to provide a suitable default metatable for
convenience:

  4.0  strfind(s,arg)
  5.0 string.find(s,arg)
  5.1 s:find(arg)

So it would be logical to expect collectgarbage -> gc.collect(),
gc.start(), etc.  It would be convenient if thread objects had a
default MT so that t:resume() can be used.

There is also a move away from excessive dependency on the global
table, which may lead to the following optional restricted mode: any
global access is a compiler error. You have to say __ENV.print;  this
becomes very tedious, so a useful bit of sugar would be:

import print,table,io

which makes suitable locals available.  Can also say 'import sin, cos
from math' of course. A little extra explicitness, and many anxieties
about global misspellings go away.

A little consistency: we know that f:method has no meaning as an
expression. It has been suggested that it can be given a consistent
meaning as function(...) return f:method(...) end, that is, it is a
closure over the self parameter. This is convenient for the common
case of providing callbacks which are methods of some object.

Now here's a concrete suggestion: people have often expressed a need
for deterministic finalizers that are called when a function goes out
of scope.  Perhaps something like Go's defer construct?

local f = open_connection()
finalize(function(e)
   f:close()
end)

that is, however we exit from this function, the finalizer will be
called.  As an error unwinds the stack, these finalizers are called
(pretty much the 'panic' mechanism of Go).  The difference is that
there is an error object which will be set if the finalizer was called
due to an uncaught error.

With the 'little consistency' above, it gets as simple as

finalize(f:close)

steve d.