On Wed, Mar 11, 2009 at 11:36 AM, Mark Miller <[email protected]> wrote:
> Both E's quasiliterals and PLT Scheme's module system suggests a
> natural extension of this idea:
>
> with syntax <language-transformer-name> <expr>
>
> where <language-transformer-name> effectively names the language
> <expr> is written in, by actually naming a parser-and-translator which
> parses the text of <expr> and translates/expands it to the BitC kernel
> language.
Scheme, and I think E, share the property that transformers must be
able to execute procedures from the partially defined program. That's
a fairly major problem for BitC.
> Your operators for combining mixfix definitions and checking them for
> ambiguity could then be generalized to combining BNF-based grammar and
> expansion definitions and checking those for ambiguity. More
> importantly, it allows the easy embeddings of DSLs with specialized
> notations.
Actually, I wasn't clear enough. Once you wrap the declarations in an
explicit "define syntax" block, mixfix notation is effectively a way
to write a significant BNF subset.
And yes; the embedding is part of the appeal.
> The hard issue, which E's quasiliterals "solve" with an unpleasant bit
> of common surface syntax, is how to allow such nested language
> embeddings to share a single cross-language lexical scope, where a
> human reader can understand these scope relationships even if they are
> not familiar with some of the languages being embedded. This helps
> code reviews and auditability.
I'm not entirely sure that I understand what you mean by
"cross-language lexical scope".
What I (hesitatingly and uncertainly) envision is block-structure in
the language syntax:
core
use syntax arith_exprs;
use syntax bool_exprs;
...
where each specialty syntax has some top-level production (I shall
call this "start"), and the main effect of a "use" statement is to
merge the start productions into the "demarcated expression"
production of the main parser and check for conflicts.
But an interesting possibility here is that the specification of a
syntax might be extended such that sub-expressions could be annotated
by a syntax-type. To give a contrived example, the logical "and"
operator is non-associative with arithmetic, but one might write
something like:
syntax bool_exprs is
start := ...
start := e1:arith_expr '<' e2:arith_expr => less_than e1 e2
end
If this is very slightly annotated so that one can bind syntax unions,
it becomes potentially very powerful.
Note that this is actually a syntactic rewriting system, where things
on the RHS of the "=>" are outputs and the production implicitly binds
labels to AST trees. The main thing missing here is support for
hygiene. The weakness in comparison to a general macro system is that
this is a purely substitution-based macro system with no capability
for computing the output AST at compile time.
I'm rambling, and I still consider all of this to be pretty iffy, but
I thought I should try to clear up the disconnect.
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
