On Thu, 2008-07-17 at 09:24 -0700, Eric Rannaud wrote:
> BTW, this is another reason to keep the current syntax: it is much
> easier to build a static analyzer for BitC with a lispish syntax than
> with a C like syntax.
>From what I have seen, there are more or less two ways of doing macros:
1. Have a syntax that cleanly distinguishes between input that is
well-formed and input that is syntactically correct. Define
a macro system that implements transforms from well-formed input
to well-formed input. These macros are processed before the input
is considered for syntactic, type, or semantic correctness.
This is actually what LISP does, and I think that it would be
possible to do this for BitC. Basically, we would define a "low"
AST form that would be straight S-expressions, and implement macros
over that.
2. Have a mechanism by which the parser can be modified by the input
in well-defined ways. The intuition here is that the parser
pre-defines all of the legal tree "shapes" that can be accepted,
and the macro system has the ability to introduce new keywords
and type constraints that are associated with each shape.
So, for example, we might have a macro that says "I want to
define a new keyword 'until' that can appear exactly where the
existing 'while' keyword can appear. Here is a procedure that
should be used to re-write that AST before symbol resolution is
performed. Here is a second procedure that checks additional
syntactic constraints that I want to impose on the argument ASTs.
Either is possible. The first is closer to the earlier macro schemes,
and it has the very real advantage of simplicity, but it occurs below
the level where the language is meaningful and it isn't terribly audit
friendly.
The second seems closer (ignoring issues of separate compilation) to
what sensible macros actually seem to do in practice, and it has the
advantage that it does not perturb the input syntax too greatly. Also,
it is potentially compatible with a block-structured language syntax.
Perhaps one might think of this as the logical equivalent to extensible
mixfix syntax, but for syntactic forms.
The problem that I anticipate here is that setting aside my personal
like for LISP, the LISP-y surface syntax actually *does* suck, and it is
going to present a significant impediment to BitC adoption. This issue
tends to push me away from macro processing solutions at the S-expr
level.
shap
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
