setfenv/getfenv

[Roberto Ierusalimschy <roberto@...>]

I will try to answer the sereval requests for our rationale for the
removal of setfenv/getfenv.

The main motivation was that, in our view, setfenv/getfenv was too
dynamic.  Basically, if function A can call function B, it can also
change the environment of B. If function A calls B, B can change the
environment of A. In other words, almost anything can change the
environment of anything.

We tried to restrict such uses. Basically, if you create a new function,
you can set its environment. Otherwise, the function itself should be
responsible for its own environment (using lexical environments).

Most uses easily fit this setting. Others may need extra work. For
instance, more than one user talked about loading a piece of code once
and running it whith different environments. I may be wrong, but
I think the following code does it (suggested by lhf):

  code = "string with the code to be loaded"
  f = loadstring("in ... do " .. code .. " end")

Now, each time you call 'f', the first argument is the environment where
the code will run. (Of course, if the original code uses the vararg, it
should be corrected to slip this extra first argument.)

We are not sure whether everything that was doable is still doable, but
the main point is that we were not sure whether everything that was
doable should be doable.

-- Roberto