Re: setfenv/getfenv

[Fabio Mascarenhas <mascarenhas@...>]

On Wed, Jan 13, 2010 at 9:00 PM, Edgar Toernig <froese@gmx.de> wrote:
>
> Could this possibly resolved with a dynamic "in-do-end"?  That is,
> "in env do <code> end" installs env as the new table of globals for
> <code> and everything <code> calls.  When end is reached (or an
> error is raised) the previous table is restored.  These in-do-end
> should nest (I admit, it's not easy to get nesting fast).
> No function environment any more, only a global environment.  If
> functions want to protect against sandboxing, they have to deal
> with that by themselves.
>
> I have no idea whether all details of a dynamic in-do-end can be
> defined reasonably (abort search, post write, direct access to
> upper levels, thread creation, a=a+1, etc).  But I would prefer
> this direction.  Just my opinion - I know there are people who
> disagree.  And there are even people who use Boost ;-)

Mark Hamburg has already suggested this (dynamic scope) in a message
last week, and even suggested an efficient implementation that
piggybacks the environment stack on the callinfo stack. Dynamic scope
has some nifty applications (google lisp special variables) but it
interacts badly with Lua 5's function environments. You seem to have
noticed that. :-)

I think function environments are a better fit for Lua's role as an
extension language, though. Having functions called by the sandboxed
functions get access to the non-sandboxed environment is ok, as all
"unsafe" (written by the user) functions will get the sandboxed
environment via loadin. This even maps nicely to the notion of
capabilities. So function environments trumps dynamic scope, even
though the latter has other useful applications. I think having both
in the same language would be too confusing.

> Another 2ct,
> ET.
>

--
Fabio Mascarenhas