[net.lang.prolog] Bug in C-Prolog Grammar-Rule Preprocessor

ok@edai.UUCP (Richard O'Keefe) (07/30/83)

     Tom Blenko reported a bug in  C-Prolog's  grammar-rule  translator.
The version of the message that reached us had the diff listing garbled,
so  I enclose  the reconstructed diff for the public good.  The file to
fix is .../prolog*/pl/grammar .

30,32c30,32
< $t_rp((T;R),S,SR,(Tt;Rt)) :- !,   % original
<         $t_rp(T,S,SR,Tt),
<         $t_rp(R,S,SR,Rt).
---
> $t_rp((T;R),S,SR,(Tt,SR=SR1;Rt,SR=SR2)) :- !, % corrected
>         $t_rp(T,S,SR1,Tt),
>         $t_rp(R,S,SR2,Rt).

     It is ironic that this  bug  still  persisted,  because  the  'C'/3
translation  was  introduced  to  fix a similar problem with unification
being pushed back before cuts.  It is possible  to  do  slightly  better
and only introduce the extra conjuncts when absolutely necessary:

	$t_rp((A1|A2), S0, S, (G1|G2)) :- !,
		$t_alt(A1, S0, S, G1),
		$t_alt(A2, S0, S, G2).

	$t_alt(A, S0, S, G) :-
		$t_rp(A, S0, S1, T),
		(   S1 == S0, G = (T,S0=S)
		|   S1 = S, G = T
		),  !.

     By the way, is typing five letters so  VERY  painful  that  "queue"
must  be abbreviated to "que" (which looks to me like a French word, and
so gets pronounced "ke")?  If so, why not abbreviate all  the  way,  and
write Q (which gets the right pronunciation)?  In any case, the last two
arguments  of nonterminals are ***NOT*** queues (a recognised and useful
Prolog data structure) but LISTS.  If  you  want  to  give  them  names,
"input  list"  and  "output  list" are more accurate than "input ke" and
"output ke", but not much more.  Consider

		append([H|T]) --> [H], append(T).
		append([])    --> [].

This is fully reversible, and if you use the Clocksin & Mellish  grammar
rule  preprocessor  (the one in their book) it turns into the usual code
for append/3 but with the last two arguments swapped.  It is possible to
write reversible translators if you are careful.  Better names for these
arguments would be  "left  list"  and  "right  list",  which  accurately
indicate both their ordering in the argument list and the section of the
parsed list that they are bound to.  (Or "full" and "residue" lists.)

     By the way, the "gconsult" program I submitted to net.sources (that
is a corrected version of the Clocksin & Mellish preprocessor) contained
this solution expressed slightly differently.  Has anyone found any bugs
in it yet?

					Richard O'Keefe
					...!ukc!edee!edai!ok
					OKeefe.R.A.@Edxa@Ucl-Cs@Isi-D