>>20899557Hmm. that's an interesting proposal as well, with the disadvantage being that the lambda calculus is not implicitly supported.
>>20899518I've refined my model a bit more.
First of all, all functions now have a scope in which they live, which means closures are partially supported in that you can close a function's temporary variables, but their state at that time is not duplicated.
Creating a function will assign this function to the current scope.
What happens when you evaluate a function is that you create a new “function scope” which includes all of the function's parameters. This way, references to such parameters inside the function's body are automatically lexically scoped to the closest match. It also means stuff like this is allowed:
>implying foo isn't >function{x int} >function{x int} >+ x xCalling >foo 5 will return another function, which when called will return its parameter doubled. So, for example, >>foo 3 5 will return 10. What happens behind the scenes:
The first >foo 3 creates a function scope and assigns to it the variable x with type int and value 3. This returns another function that lives inside this scope (the internal x is not yet replaced because it is bound to the function's signature, and thus not a free variable).
Calling the result of this again, creates a secondary function scope /inside/ the scope within which the function lives, inside this scope the x will be 5 (in its parent scope x will still be 3). So when you finally evaluate >+ x x, what happens is that both x occurrences recursively move upwards in scope and thus both match the inner “5”, returning 10 as a result.
If a function returns anything other than another function, its calling scope is destroyed afterwards.
How does this proposal sound?