# Compiling E: Phases of Transformations

Mark S. Miller markm@caplet.com
Wed, 09 Aug 2000 13:28:40 -0700

```At 01:02 PM 8/9/00 , Dan Bornstein wrote:
>So I have to ask: Why make quasiparsers recognize it? Why not just pass in
>an array of hole locations as a separate argument to the quasiparser, the
>same way you propose to pass on span information?

Quick answer: because I never thought of it!  Hmm...

>(You'd presumably also do the conversion of \$\$ before the quasiparser saw it.)

Nope, doesn't work.  E knows not to interpret \$\$ and @@, but then it passes
them unmolested to the quasi-parser.  So, in the current mapping:

e`\$\$a + \$b`

expands to:

e__quasiParser valueMaker("\$\$a + \${0}") substitute([b])

e__quasiParser valueMaker("\$a + \${0}") substitute([b])

what would I do about source text like

e`\$\${0} + \$b`

?

But if I take your first suggestion, then I no longer need to have
quasi-parsers understand \$\$ and @@.  E would still need to understand them
to do the expansion.  But they could be collapsed during E's expansion,
rather than making each quasi-parser do this collapsing itself.  The above
source expression could expand to

e__quasiParser valueMaker("\$a + ", [5]) substitute([b])

Where 5 is the position in the string being fed to the quasi-parser where I
would have placed "\${0}".  Only quasi-lexers need to understand this
array of hole locations.  They can produce hole-tokens -- that can't be been
written in the grammar's source language -- for parsers to deal with.

OTOH, as is, the above proposal makes the quasi-string by itself unreadable.
Perhaps we should put something at the hole location.  Now that we have an
array of hole locations, the text we put at the hole location doesn't have
to be unambiguous by itself.  How about "\$" and "@"?  We would now expand to:

e__quasiParser valueMaker("\$a + \$", [5]) substitute([b])

This also provides enough redundancy to catch some simple errors early.  I
think I like it.

Cheers,
--MarkM

```