Parser clarifications

Tomas Lozano-Perez (tlp@ai.mit.edu)
Mon, 9 Mar 1998 09:37:38 -0500 (EST)

I didn't think it needed saying but someone was bit by this...

The version of the parser I distributed yesterday assumes that the
first element of every assertion is a constant symbol, e.g. (NP ?x),
(PP ?x) etc and not (?x NP). It uses this fact to quickly discard
most rules and/or assertions as irrelevant to a match. Please don't
write rules with variables in the car of the assertion. You should
not need to do this and the rules will be very hard to interpret if
you do.

Also, there is some question about why the top-level goal for
backchain is

(backchain '(S (? syn) ,input ())) in grammar.scm
(backchain '(S () () (? syn) ,input ())) in grammar2.scm

The rule pre-processing code (in grules.scm) adds variables to
every component of a :grule, as follows
'(:grule (NP) (VP) -> (S))
generates the equivalent of
(if (NP ?np-syn ?s0 ?s1) (VP ?vp-syn ?s1 ?s2)
then (S (S ?np-syn ?vp-syn) ?s0 ?s2))
The variable ?np-syn binds the "parse tree" for the NP, the var
?vp-syn binds the parse tree for the VP and then the parse tree for
the S is constructed as (S ?np-syn ?vp-syn). We've seen that the ?s_i
vars are used to bind the start and end of each phrase. So, in order
to match an S assertion as produced by the rules, the backchain needs
to have the same structure.

The grammar2 situation is similar except that now an S assertion has
two "gap" variables, the () () in the backchain goal are simply
providing a place for that. We use constants instead of variables to
make sure that the final S assertion has no uninstantiated variables
in it. This is a kludge to make up for a deficiency in that simple
grammar. The top-level S assertion should not have those gap
variables in it. We should really have an intermediate level clause
that handles the gap, and the a rule that goes from there to the S.
But I didn't want to complicate the grammar too much.

Please let us know if you have more questions,
Tomas