[Omake] Higher-order functions with "export transparency"?

[Jason Hickey]

Coincidentally, I have been considering the same issue (on my release  
TODO list).

Private variables have never been exported (unless explicitly).  The  
reason why it comes up now is that function parameters have become  
private; they used to be "this" variables.  The beauty of private is  
that they are statically scoped, and they do not "leak" like "this"  
variables do.

But the following code now does the "wrong" thing.  Since "s" is  
private, the export has no effect.

    f(s, l) =
        foreach(i => ..., $l)
            s = $(add $s, $i)
            export
        return $s

I think an "export .PRIVATE" is too tricky.  Q: why not always export  
private variables?  A: private variables are statically scoped, so an  
export could kill variables that were previously live.  It isn't  
because it is such a useful feature...

In old-0.9.9.x, private exports succeed iff the two (or more)  
contexts are in the same static scope, like "f" above.  That is,  
exporting from an inner static scope to an outer one is allowed.   
Exporting private variables between unrelated static scopes fails  
(unless written explicitly).

     g() =
         private.x = 1
         export
     private.y = 2
     h() =
         private.x = 3
         g()
         # x = 3, y = 2

This rule prevents variables from being killed, and I believe it also  
preserves the intuition without being too surprising.  It is probably  
time to resurrect it.

Jason

On Oct 25, 2007, at 10:00 AM, Aleksey Nogin wrote:

> Currently the private variables would not get exported, unless  
> explicitly given as arguments to export - even when the export is  
> within the scope of the original declaration for the variable. This  
> is mostly OK in most cases - except for the cases of higher-order  
> functions.
>
> The most obvious example is foreach methods (Object.object-foreach,  
> Sequence.foreach and Map.foreach). It would have be natural (IMHO)  
> if foreach methods were "transparent" w.r.t exporting - where  
> anything exported by the foreach body would get exported by foreach  
> itself. This is not how it currently works - any exports of the  
> private variables would be lost.
>
> Jason, I do not have a good intuition for different variable  
> classes yet, so I would really appreciate if you could comment  
> whether you think adding something like "export .PRIVATE" that  
> would export all private variables that exist in the outer scope  
> would be reasonable. I assume that an unqualified "export" would  
> probably still default to _not_ exporting private variables, but  
> "export .ALL" would probably export everything (although we may  
> also choose to require an explicit "export .ALL .PRIVATE", if we  
> wanted to be really strict about private exports).
>
> The obvious place to use this would be in definitions of the  
> foreach methods (I am sure you are very happy about the idea of  
> adding yet another feature to the language just to get foreach work  
> the way I like them ;-) ), but I am sure that having an  
> "export .ALL" sections would help simplify other functions as well.
>
> To be honest, I am not even sure if any natural semantics  
> "export .PRIVATE" would support the "export transparency" goal. The  
> most obvious semantics is to say "export .PRIVATE" is "export all  
> the variables in current static scope", but the "export  
> transparency" requires re-exporting all the static variables in the  
> _caller's_ static scope, not in the HO function one... In the worst  
> case, it could be that an accurate definition of the semantics that  
> I want would require dealing explicitly with the static  
> environments along the current call stack (obviously a route that  
> we would not want to go into, unless we are willing write a CPS  
> compiler for OMake).
>
> Or perhaps we should just change how we do the foreach? Instead of  
> having the different foreach methods that return a HO function, we  
> could do it the Python way, where there are different iterator  
> methods, but only one built-in foreach that does not have to follow  
> the function call semantics?
>
> Aleksey
> -- 
> 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