A great deal of thought has gone into the representation of functions in the SANE version.
It is important that a function lives within an environment. There are no "stand alone" functions. Given a function its environment contains the representation which itself is a function type with accessor functions. Wrapped around these is the domain type containing other functions. The domain type lives within several preorders of environments, some dictated by the structure of group theory, some dictated by the structure of the logic. Lisp has the ability to construct arbitrary structures which can be nested or non-nested, and even potentially circular. Even more interesting is that these structures can be "self modified" so that one could have a domain (e.g. genetic algorithms) that self-adapt, based on input. Or "AI" domains, representated as weight matrices, that self-adapt to input by changing weights. Ultimately the goal of the representation should be that, given a function, it should be possible to traverse the whole of the environment using a small, well-defined set of well-typed structure walkers. All of this is easy to write down in Lisp. The puzzle is how to reflect these ideas in Spad. Currently the compiler translates all of the Spad code to Lisp objects so the Spad->Lisp conversion is easy. Lisp->Spad is also easy for things that have a surface representation in Spad. But, in general, Lisp->Spad is only a partial function, and somewhat limited at that. I suspect that the solution will allow some domains to be pure Lisp and others will allow in-line Lisp. Most of these ideas are nearly impossible to even think about in other languages or, if attempted, fall afoul of Greenspun's Tenth Rule, to wit: "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp." Fortunately Spad is only a domain specific language on top of Lisp. Once past the syntax level it is Lisp all the way down. Tim