Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!bloom-beacon!eru!luth!sunic!mcsun!unido!stollco!he
From: he@stollco.UUCP (Helge Oldach)
Newsgroups: comp.lang.prolog
Subject: Re: grammar for prolog
Summary: Operator precedence parsers suits
Keywords: grammar, YACC
Message-ID: <160@stollco.UUCP>
Date: 9 Oct 89 18:50:03 GMT
References: <585@nikhefk.UUCP> <2293@munnari.oz.au>
Organization: Stollmann Gmbh, D 2000 Hamburg 50
Lines: 23

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.