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

[Aleksey Nogin]

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