30 mar 2009 kl. 14.45 skrev Marc Feeley:
We can argue over the name (syntax-begin, begin-syntax, for-syntax, meta, ...),
Indeed. I'm not quite content with the name syntax-begin, it just doesn't feel elegant. But at this stage of development I felt it was more important to get a proof-of-concept out than having the perfect name. I picked it because it seems like that name is rather unique, and a long name is ok since it isn't used all too often.
syntax (what is allowed inside the form?)
In the current implementation (if I understand the code correctly): Anything that's allowed in the REPL is allowed inside syntax-begin. Right now it's implemented simply with eval and some toying around with the hygiene environment. I haven't really spent the time to think what this actually means to what is allowed.
I chose the name syntax-begin because I made the semantics to resemble that of begin: (syntax-begin (+ 3 3) (+ 2 2)) macro-expands to 4.
Possible problems I see at the semantic level are
- 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).
Hmm.. Yes. Could you give a more concrete example where the problem would arise? It seems PLT's module system does things to avoid this kind of problems, but I haven't fully understood when they arise in practise.
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.
I'm not sure I understand what you mean by syntax environment. Do you mean a set of global variables, or just a set of bindings to globals?
In the current black hole implementation every module (and the REPL) has its own syntax environment in the weaker sense that they have their own namespace. You'll need to pull some bug fixes I did today if you want to try it out.
/Per