Build Problems Resolved
Mark S. Miller
Wed, 01 Sep 1999 18:46:06 -0700
At 04:53 PM 9/1/99 , email@example.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.
>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
>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
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.