Closures

a.k.a. unnamed functions

closure-param     ::= spec parameters then
closure           ::= { [closure-param] statements }

The parameter specification can be skipped, in which case the parameters can be refered to as @1..@n, and their types will be derived from the environment.

If you use the parameter specification, you can use @ as a generic type and the type will be derived (as in the case of no parameter specification) from the environment.

Nota Bene: if the environment has several matches (in case of overloading), then you must specify enough types to limit to matching set to one.

Closures do not support: return, yield, or fail.

Closures can use variables from their lexical scope. If it does, then a closure will result in the creation of one (1) extra code block per invocation of the closure definition:

1. The extra function will have the 'contract' of the environment. It will also have a Parameters from_scope, which it will use to extend the parameter list and call the closure function.
2. The closure function will contain the code as defined in the closure expression.
   Note that after the return of this function the changed my variables will be stored in from_scope, thus ensuring that all 'inherited' will remember their changes.

my

my

the

that

an

that

shared

that