Currently our compiler doesn't support functions or closures with
non-constant initforms. The interpreter does, but not the compiler.
The reason for this difference is quite straight forward: the
interpreter and compiler both use
Closure.processArgs()/fastParseArgs() to parse the arguments list and
calculate default values for parameters-not-provided. The interpreter
has the interpreter environment available when doing so, meaning that
the interpreter has the full lexical environment to evaluate the
The compiler (currently) has no way of transferring the lexical
environment to the interpreter: because of runtime speed, the compiler
uses Java variables to store the lexical context, not the Environment
This means that all closures created by the compiler contain a null
Environment, because the references to the variables are hard-coded in
the compiler output. This means that processArgs() doesn't have the
context it needs to evaluate the initforms.
Now, there are supposedly 2 ways of resolving this issue:
1) Make the context available to processArgs() by creating a lexical
environment at run time when needed
2) Compile the parsing of arguments into each function which needs
that, using the lexical environment as established by the compiler
Last October, I was working on (1), but I estimate runtime cost:
environment records need to be created for every call to a function
with non-constant init forms. Now, I'm thinking (2) may be favorable,
but will cost a lot more storage space: nearly the same code will be
repeated in lots of places, depending on whether we *always* compile
argument parsing or that we do it only for non-constant cases.
So, I'm basically posting this because of 2 reasons: first of all, I'd
like your opinions, but second of all, I'm hoping some of you may know
how other implementations handle this issue.
With kind regards,