RE: Build Problems Resolved Mark S. Miller (markm@caplet.com)
Wed, 01 Sep 1999 18:46:06 -0700

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