Re: setfenv/getfenv

[Jerome Vuarand <jerome.vuarand@...>]

After reading others complaints about the "uglyness" of concatenating
code to a chunk to be able to change its environment dynamically, I
remembered that one of Lua's great use is being a basis for DSLs, and
good control over the environment of a function (from the outside) is
important to implement many DSLs.

2010/1/12 Roberto Ierusalimschy <roberto@inf.puc-rio.br>:
> 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).

One way to restrict such abusive uses, which can easily become a mess
(I guess all agree on that), would have been to restrict
setfenv/getfenv so they no longer can take their integer parameter,
ie. they can only modified a function that is passed directly as a
reference rather than a call stack index.

That way modifying your caller environment is still impossible (but
here the lexical environments fill the gaps, as the new 'module'
function show), at least not without the debug library. But you can
still modify a callee environment before calling it, eventually
several times with different environments.

The rare cases where the callee may need to modify the caller in a DSL
are often situations where the modified function is sandwiched between
two layers of the framework (ie. framework call DSL which call some
framework.helper), and this can be solved by appropriate cooperation
between the two framework layers.

IMHO that sounds like a good intermediate solution.