[Omake] SVN Commit: OMake Build System [0.9.8.x] (Rev. 11352)

[Aleksey Nogin]

On 19.07.2007 14:51, Jason Hickey wrote:

> Proper methods that export also redefine the head variable in the method 
> path.
> 
>    foo. =
>        i = 0
>        incr() =
>            i = $(add $i, 1)
>            export
> 
>    foo.incr()
>    foo.incr()
>    # foo.i = 2
> 
> If foo did not get redefined, the export would have no effect.

Oh, I see now.

> We get the conflict when the head variable is the same as a definition 
> in the body.
> 
>   foo. =
>      boo() =
>         foo = 1
>         export
> 
>   foo.boo()
>   # What is foo?
> 
I would propose the following semantics - when we do "foo = 1", we have 
essentially shadowed the previous foo definition. Semantically the 
"export" both hoists and shadows - first hoists "this" into foo, next 
updates the "foo" binding to point to 1. However, the former action is 
invisible as there is no way to access it's result.

Another way to think about this semantics is that the hoisting updated 
the "old foo", but that "old foo" is no longer accessible, as the "new 
foo" have shadowed it. Yet another way - direct update has higher 
priority that indirect one. Or - that binding of a name to a value is 
stronger that the binding of a name to its object namespace.

Implementationally this would probably mean something like.
  - first do the normal functional export
  - next, see if the value of the head variable is == to its original value
  - if so, hoist the "this" into it.

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