playing around with the add-json package, I realized that I will need to "extend" functions like the path_func at some point. That is, I need to calculate a value using the original version of the function and "add" my calculations on top. My approach is to wrap the function, which works as long as I don't need "multiple versions" of that function. In the latter case closures would help, e.g.:
function do_add(i: int): function(j: int): int
{
return function(j: int): int {return i+j; };
}
In the light of the flexibility that comes with packages, I think supporting closures would be a nice feature. Was there any fundamental design decision against supporting closures?
I think it's mostly unsupported due to trickiness of implementation
(or cowardice) rather than by design decision. Or at least something
scared me off when I looked into it a few years ago [1]. Don't
remember the details, though I likely didn't give it more than a day
or two of thought/effort, so maybe don't let that deter you if you had
plans to look into it.
On 19/12/17 18:31, Jon Siwek wrote:> I think it's mostly unsupported due to trickiness of implementation
(or cowardice) rather than by design decision. Or at least something
scared me off when I looked into it a few years ago [1]. Don't
remember the details, though I likely didn't give it more than a day
or two of thought/effort, so maybe don't let that deter you if you had
plans to look into it.
Indeed, it seems tricky to get that working! I am not sure I will be able to find the time to look deeper into this. At a first glance, I would try to wrap function IDs into a new Val type that is able to carry the context. The particular context would be determined, when evaluating the expression, which returns the anonymous function. In the end, when the function is called, the context values could be treated as additional arguments.