Re: stack level parameter

[Mark Hamburg <mark@...>]

On Jan 19, 2010, at 10:44 PM, Juris Kalnins wrote:

> On Tue, 19 Jan 2010 17:25:36 +0200, Mark Hamburg <mark@grubmah.com> wrote:
> 
>> This approach is quite different from what Lua does now but at the same time is fully compatible with most code (under the assumption that setfenv is rare and getting rarer and hence most code was operating in a single shared environment anyway).
> 
> I might be mixing something up, but is it really compatible with current
> code? Like module definitions:
> 
> module "A"
> function dothis() end --define A.dothis
> function dothat() dothis() end --define A.dothat, FAIL when called
> 
>> It has pros and cons depending on what you want to do. One increasingly big pro for me when I look at it is that it is actually moderately easy to describe. It's also much more friendly toward threaded (coroutine) code than uses of setfenv at any time other than immediately after code has been loaded.
> 
> It is a completely new mechanism. If you replace current environment handling
> with this, you get a very different language, semantically.
> Better - maybe, but different (userdata environments, modules, ...)
> If you add it as additional possible name binding, then I think there
> would be a total confusion, unleast you declare variables explicitly:
> 
> local a; dynamic b; global c;

Userdata environments are unaffected. The only thing they had in common with function environments was the API that happened to be used to get and set them. The existing C API routines could be renamed lua_getudenv and lua_setudenv under this proposal.

The effect is on function environments.

	module "A"
	<< definitions >>

becomes:

	in module "A" do
		<< definitions >>
	end

But this is an expected change for 5.2 anyway with the existing module swizzling being preserved purely for code compatibility and with some controversy about doing that -- i.e., if we're changing how module is supposed to be used, let's change it.

What does change in defining modules is that if one is relying on the global environment rather than local variables to find other pieces of the module, it probably isn't going to work. Basically, you end up with two ways to work under this proposal:

1. Don't change environments anywhere -- i.e., don't use in-do-end -- and it behaves just like Lua 5.1 minus setfenv, getfenv, and module.

2. Make increased use of locals when you want to preserve a particular reference and use the now dynamic globals for those cases where you don't want to lock down the reference.

As I said, this language has different semantics from Lua with respect to globals, but it's probably not as different as one might think for most code.

Mark