Re: setfenv/getfenv

[Cosmin Apreutesei <cosmin.apreutesei@...>]

> 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).

This phrase says it all really, but you gotta admit Roberto's
overly-concise way of putting it doesn't seem to strike us with
enlightenment on the first read, thus this record-long thread :)

So allow me to rephrase it as I understand it (and correct my vision
where distorted):

A function has a home environment decided lexically by its creator
(eg. its module chunk, its class etc.). Callers can only influence the
function's behavior through it's public interface, i.e. it's
arguments. The function's environment is not part of that interface,
so callers shouldn't try to mess with that environment to change the
function's behavior that way. They should instead squeeze the new
environment into a formal parameter and let the function decide (using
the `in` construct) how and when to use it to abstract its own
behavior with it. Likewise, a function shouldn't be able to access the
caller's environment and introduce a hidden contract with it. It's
otherwise ok for a function to have a hidden contract its home
environment (i.e. have access to a global state restricted to that
environment).

With this perspective in mind everything comes into place and no
functionality is lost -- that is, if you accept the idea of to
surfacing out a function's modifiable environment(s) into formal
parameter(s), and consider its initial home environment as read-only
thus avoiding using the debug module. The behavior of `in nil do end`
also fits nicely with optional parameters.

loadin() cleverly closes the lexical "gap" at the same time avoiding
the need for the more practical envcall(enf,f,...) which would
more/less get us back where we started protection-wise :)

That being said, I'm still intrigued by Mark's idea of putting the
function's environment in CallInfo
(http://lua-users.org/lists/lua-l/2010-01/msg00437.html) and adding
ecall() (rhymes with pcall() why not). Without this, DSLs are
officially becoming a hack.


PS: I see exceptions got no attention in this release. Maybe in 6.0 :)