Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!samsung!munnari.oz.au!goanna!ok From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) Newsgroups: comp.lang.prolog Subject: Re: Looking for source code for Prolog (general) Message-ID: <5629@goanna.cs.rmit.oz.au> Date: 8 May 91 07:24:46 GMT References: <1991Apr30.075951.9679@news.iastate.edu> <5525@goanna.cs.rmit.oz.au> <1991May2.155052.16813@hubcap.clemson.edu> Organization: Comp Sci, RMIT, Melbourne, Australia Lines: 41 In article <1991May2.155052.16813@hubcap.clemson.edu>, raghutp@hubcap.clemson.edu (Raghu Toppur) writes: > In article <5525@goanna.cs.rmit.oz.au>, ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: > > You cannot parse Prolog using Yacc, because Prolog is not an LR(1) > > language. > Surely there is a "subset" of Prolog language for which an LR(1) grammar > could be used? My question is briefly as follows: What aspects of Prolog > syntax cause it to be non-LR(1)? Operators. If you restrict yourself to the operators of C Prolog, and adopt the rule found in C Prolog 1.*.edai that - a token following ( [ { , | cannot have a left operand (so is not an infix or postfix operator) - a token preceding ) ] } , | cannot have a right operand (so is not an infix or postfix operator) - if an atom is preceded by something that _must_ be a left operand of it, then it will be read as an operator even when followed by (, so that 1+(2) is the same as +(1,2). then you shouldn't have much trouble. > Is the "op" predicate considered central to the definition of Prolog ? > That would mean that the yacc-parser I've been using > so far isn't fully complete (yet!) and never will be. It all depends on what you mean by "Prolog". Let's face it, without user-definable operators, Prolog syntax is so _trivial_ that there just isn't any point in using Yacc. I've got a Prolog syntax checker built into the editor I'm using to write this message, and the C code is shorter than any Yacc grammar I've seen for Prolog, and was a heck of a lot easier to debug. Good Prolog programmers do not define many operators. If you want to run existing code in textbooks (such as Peter Ross's rather nice book), you had _better_ be able to handle user-defined operators. If you just want to explore the really important ideas, you might as well use Lisp syntax (micro-PROLOG did, and HP used to distribute a Prolog with a Lisp syntax option. (Why don't people ask about Yacc grammars for Lisp? CL syntax is at least as complex as Prolog syntax...) -- Bad things happen periodically, and they're going to happen to somebody. Why not you? -- John Allen Paulos.