[Omake] test/object/Test14

[Aleksey Nogin]

Jason,

Consider the following:

-----------------------------------------------
A[] = key

Test(map) =
    A.foreach(key)
       map = $(map.add $(key), new)
       export map

    new = $(map.find key)
    if $(not $(equal $(new), new))
       println($"Error: expected new, got $(new)")
       exit 1

X. =
    extends $(Map)
    $|key| = old

Test($X)
---------------------------------------------

This does print the error message in 0.9.8.x. However, if "map" was a 
global variable (not a function argument), as in Test08, then it would 
work right.

The issue is that the path export only exports the dynamic environment, 
skipping the "this" (like the normal export would do). This is no longer
a conflict between the preserving variables in the body, or the variable 
in the hoist, like in Test08 (my rev. 11448 fix resolved that conflict).

How should we address this? Note that there is an opposite problem here 
as well (the map variable becomes a field in $(A)!).

I think that the semantically correct solution is the following table

Variable is present in         Value that should be used in
orig.this  obj  new.this         hosted obj      output_env
    Y        Y      *             obj/new.this     orig.this
    Y        N      *                 N            new.this
    N        *      *             obj/new.this        N

In other words, for each variable we have to consider 2 cases:
- If the variable existed in the "this" namespace of the original 
environment (before the function call), but not as an object field, then 
  we assume that any reference to it within the function refers to the 
"this" namespace. The variable should not get hoisted.
- If all other cases (including if the variable existed _both_ in the 
"this" namespace of the original environment and as an object field), we 
assume that any reference to it within the function refers to the object 
field. The new value of the object field is based on hoisting; the value 
  (if any) in the "this" namespace remains unchanged.

Is this reasonable?

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