Build Problems Resolved

[Mark S. Miller]

At 04:53 PM 9/1/99 , mzukowski@bco.com wrote:
>Excellent overview.  I'm having a disconnect on some things.  What's the
>difference between the $ and the @?  Does $ substitute and @ match?

Exactly.  After a $ comes an E expression that provides the value to 
substitute.  After a @ comes an E pattern that is matched against the value 
extracted from the original specimen.

>So your
>first match in there substitues in var, then parses it and then matches it
>filling in exp with a subtree?

I couldn't parse that ;)

>How exactly to you match trees?  Do you first compile the match expression
>into a tree and then compare the results?

That happens to be how I do it, but it doesn't have to be how I do it.  An 
observably identical quasi-pattern parser could instead produce a 
MatchMaker containing code for a decision tree compiled from the original 
string.  Think about compiling Prolog clause-heads to Warren Abstract 
Machine instructions.  Similarly, a ValueMaker could contain code for 
generating a tree, without itself containing a tree.  The analogy here 
might be Prolog clause-bodies.

>How do you distinguish between parents and children?

I don't understand.

>My mindset is dominated by having the parser driving the control of a
>program, so maybe I'm just not "getting it" or I'm trying to solve problems
>which aren't appropriate for quasi-parsers.

I'm not really familiar with ANTLR (I did skim the web pages), but I think 
you put your finger on it: In E, each parser is a small component within a 
large program written in a general purpose computer language.  The 
super-structure is regular programming, not parsing.  Parsing is only for 
special subproblems.

>OK, yours is much much easier to read as far as what is output.  But you are
>matching trees against trees and not really parsing trees, I think.  Why
>does that matter?  Overhead, and generality.  You have to generate a tree
>for every expression you match against.

As explained above, I am, but I don't have to.  Similarly, my "rx" 
quasi-parser builds a Perl5 regular expression matcher for each regex 
string.  This object matches specimen strings, rather than having to 
interpret a pattern-string at match time.

>Hmm, I have more thinking to do.  Given a separate grammar you could enter
>it from a quasi-pattern...or you could specify grammar fragments in the
>quasi-pattern... but you don't want to parse a whole program, just a sub
>tree...

I'm not sure what you're saying, but it sounds right.

>Sorry my thoughts are so fragmented.  I'll return to it tomorrow.

Looking forward to it.


         Cheers,
         --MarkM