Re: stack level parameter

[Mark Hamburg <mark@...>]

On Jan 18, 2010, at 10:28 PM, steve donovan wrote:

> On Tue, Jan 19, 2010 at 6:56 AM, Mark Hamburg <mark@grubmah.com> wrote:
>> This is arguably one of the strongest arguments for the dynamic scoping proposal. in-do-end already deals with one of the chief reasons to use a stack level index in setfenv. Dynamic scoping would deal with one of the chief reasons to do an indexed getfenv.
> 
> I get worried by the phrase 'dynamic scoping', since it implies that
> one can never tell what environment is currently loaded. Is the idea
> to use it instead of the current trick of resetting a function
> environment?  What are the abuse scenarios?

The summary is "functions don't have environments, call frames (activation records) have environments". (Calling a function preserves the current environment. in-do-end temporarily changes the current environment.)

It's hard to say what the abuse scenarios are without a definition of what constitutes an abuse scenario. Certainly it probably pushes harder for using other mechanisms like upvalues to share private data since everything you call will by default be able to see the same globals you can see. On the other hand, you can readily sandbox anything with no concerns over re-entrancy by changing the environment before you call it. This is something you can't do with setfenv.

Mark