[Omake] test/object/Test14

[Aleksey Nogin]

On 01.08.2007 11:11, Jason Hickey wrote:

> You seem to 
> be arguing that, in the following, the "export map" should refer to the 
> function parameter, not the field of A.  Is that right?
> 
>> Test(map) =
>>    A.foreach(key)
>>       map = $(map.add $(key), new)
>>       export map
> 
> I'm not sure I understand the argument you are making.

There are at least 3 separate arguments here, each working on a bit 
different level.

1) "Naive user / principle of lease surprise" argument. The goal of 
foreach is to be a simple iterator. For an array A, there should not be 
a difference between "A.foreach(key)" and "foreach(key, $A)".

2) "Namespaces" argument. Prior to the method call, we have to disjoint 
unrelated namespaces - the "this" namespace of the caller and the object 
fields namespace. Our implementation not only confuses the two, but 
allows the object namespace to "steal" from the "original this" namespace.

Note that in the above example, even if "map" was not an object field, 
it will become one under your semantics. Also note that the fact that 
the function arguments are currently in "this" namespace only makes it 
easier to hit this problem, but it has no direct relation to it.

3) "High-level straightforwardness" argument. Fully exported fragments 
of code ought to be locally equivalent to imperative interpretation.

Note: this is probably the weakest argument as the above example can be 
regarded as imperatively mutating the "map" field of the object.

---------------------------------------------------------------------

Now that I have thought about this more, I agree that my solution is 
wrong (the main problem with it is that I do not like that the 
"namespace meaning" of the above code example depends on whether $A had 
a field called "map"), although no worse than the original path hoisting 
one.

I believe that either of the following approaches would make things more 
consistent:

1. Make it so hoisting applies only to variable assignments that are 
_statically_ within the scope of a method. This may be tricky to 
implement (unless we make the whole "this" scope statically scoped?), 
but it would be nice.

2. Force users to specify path-exports manually (e.g. "export this.map", 
"export .THIS", etc) with the default being to do the usual export.

3. A hybrid solution between the above two. When the user does not 
specify explicit path exports, then consider as path-exported all the 
exported variables that _may_ be assigned to (on any control path) 
within the _static_ scope of a method. So the evaluator will work 
exactly like in solution 2, except the "path-export" annotations will be 
automatically inferred to emulate solution 1.

4. Speaking completely hypothetically (as this probably does not match 
any of the 9.8/9.9 approaches to naming), we can add another 
indirection, where we have the environment has a collection of 
namespaces, plus a map resolving "this" to one of them. There, when 
calling the body evaluation from the method, we'd restore the "this" 
pointer to the original "this" namespace and then reset it back after 
the body is done...

Aleksey
-- 
Aleksey Nogin, Research Scientist
Advanced Technologies Department, Information & System Sciences Lab
HRL Laboratories, LLC, Malibu, CA