Several people have suggested adding DEFMACRO. The topic of DEFMACRO is
properly a subject of holy wars. Setting aside semantic problems with
the whole idea, however, I want to explain here why this is harder than
it looks.
BitC really isn't an S-expression language. It just looks like one.
A little examination will reveal that while datatypes for both SYMBOL
and lisp-style LIST might easily be created, they are nowhere primitive
in the language. This is on purpose. The provisional intension is that
writing
'(some-form)
will yield an AST whose type is defined in the BitC standard library.
Note that for support of the prover, the AST format may need to allow
parameter variables.
In any case, what this means is that DEFMACRO would need to operate over
ASTs rather than lists. While macro processing definitely *can* be done
in this way, it is not nearly as convenient as the LISP equivalent.
At the moment, I am very torn between rejecting DEFMACRO because it is
such a swamp what it should do (and has been for years), and adding it
because it would be so useful to be able to experiment with new
syntactic forms.
This is something that I need to defer for now so I can get my grant
proposal out, but I wanted to point out the AST thing and make people
aware that I do see both sides.
shap
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
