[Omake] test/object/Test14

[Jason Hickey]

To me this is a bit frightening--trying to fix naming problems by  
introducing some short-term policies in 0.9.8.x.  It isn't always  
easy to undo the "fix" when it reaches the naming branch, because of  
conflicts.

Why is it important to address this now, when there is a jumbo branch  
devoted entirely to naming?  I'm not saying that this is as fixed as  
you would like in the naming branch.  I'm just saying that I would  
prefer to "get it right once" rather than "get it right twice".

I already know that 0.9.8.x has issues with naming.  That's the  
reason for the naming branch in the first place.

Jason

On Jul 31, 2007, at 3:32 PM, Aleksey Nogin wrote:

> 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
> _______________________________________________
> OMake-Devel mailing list
> OMake-Devel at metaprl.org
> https://lists.metaprl.org/mailman/listinfo/omake-devel

--
Jason Hickey                  http://www.cs.caltech.edu/~jyh
Caltech Computer Science      Tel: 626-395-6568 FAX: 626-792-4257