🚀 go-pugleaf

In article <2293@munnari.oz.au>, ok@cs.mu.oz.au (Richard O'Keefe) writes:
> In article <585@nikhefk.UUCP>, henks@nikhefk.UUCP (Henk Schouten) writes:
> > I am looking for a description of the grammar of the Prolog language to be
> > used in building a syntax checker with Lex/Yacc. 
> [...]
> (E) The bottom line is that Yacc is not able to handle the full syntax
>     of Prolog.  You would have to restrict it by leaving out user-defined
>     operators and user-defined macro-processing.  The result would still
>     be a useful language.  But it would not be a very interesting one to
>     use as a class project, because there is very little that a syntactic
>     analysis can reject.

I agree. My solution (some years ago) was to write an operator precedence
parser for Prolog. The syntax is very straightforward: you just have
operands, operators and brackets. And (this was my main motivation):
there was no harm implementing extensible sets of operators.

>     The Prolog parser in my editor is, excluding
>     the tokeniser, about 200 lines of C.  About a third of that is
>     disambiguating operators.  That really doesn't sound as though it
>     would make an interesting Yacc grammar.

I agree, again. My parser was (I hope, it still *is* :-)) very small, too.