Compiling E: Phases of Transformations

[Mark S. Miller]

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])

If I expanded instead to

     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