On 30-Mar-09, at 6:10 AM, Per Eckerdal wrote:
Does this make sense? Or am I trying to solve a non-problem? Is this overly difficult to understand?
No, it makes perfect sense (to me).
We can argue over the name (syntax-begin, begin-syntax, for-syntax, meta, ...), syntax (what is allowed inside the form?) and scope. But basically such a mechanism is necessary to distinguish the run time environment and the syntactic environment(s).
I assume that
(syntax-begin (syntax-begin (define (foo) ...)))
would define foo in the environment of the syntactic part of the syntactic part of the run time environment.
Possible problems I see at the semantic level are
1) The global variables are shared. Global variable X in the syntax environment is the same variable as global variable X in the run time environment. So in the interpreter, if you load a file containing
(syntax-begin (require srfi-1))
then all the procedures defined in srfi-1 will persist. They will be available to subsequently loaded files, and the REPL. However they are only available with a fully qualified name (srfi-1#append!).
2) This could be "fixed" so that each level of the tower has its own set of global variables, but I am worried about the cost of duplicating many variables (to be consistent all the Gambit predefined variables would have to be duplicated). Also I'm not sure this would be right semantically. Perhaps each module should have its own syntax environment, in other words it is not a single tower but a set of towers (*not* a tree). This is the purest model that ensures that something defined for syntax in one module is not available to the syntactic part of another module.
Marc