tnbf6@isuvax.iastate.edu (04/30/91)
I am currently working on a project, and am looking for examples of how to parse prolog efficently (preferably using c or yacc code). Could anyone direct me to sites with FTP-able prolog source code, and/or books documenting how to create prolog parsers (I have noticed that many books on begining prolog give a rudiementry sketch of the prolog heirarchy, but they tend not to go into full detail) Thank you in advance. Norman Nunley --- tnbf6@ccvax.iastate.edu
kjell@ygdrasil.ucsc.edu (Kjell E Post) (04/30/91)
tnbf6@isuvax.iastate.edu writes: >I am currently working on a project, and am looking for examples of how to >parse prolog efficently (preferably using c or yacc code). Could anyone >direct me to sites with FTP-able prolog source code, and/or books >documenting how to create prolog parsers (I have noticed that many books >on begining prolog give a rudiementry sketch of the prolog heirarchy, but >they tend not to go into full detail) Thank you in advance. >Norman Nunley --- tnbf6@ccvax.iastate.edu Depends on your ambition level. If you don't want operators it should be fairly easy. Just take the grammar from the DEC-20 manual and yaccify it. The grammar is also reproduced in the manuals for SICStus and Quintus Prolog. [Disclaimer: I haven't tried this but w/o operators it should be easy.] If you want operators, well... the language is then no longer static since operators can change fixity and associativity dynamically while you're parsing the input file. Probably the best thing to look at is the public domain parser read.pl. Send me mail if you want me to dig it out for you. The syntax of the language is in a sense defined by this program. ISO is working on a more formal document. -- | | |\ /| |\ |\ | Kjell Post | Vi i Sverige har blivit | /|\ | \/ | | \ | \ | CS Grad Student, UCSC | trygghetsnarkomaner. /|\ \|/ | | | | | email: kjell@cs.ucsc.edu | Livet best}r inte bara av / | \ | | | | | `--------------------------' trygghet. --Curt Nicolin
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (05/02/91)
In article <1991Apr30.075951.9679@news.iastate.edu>, tnbf6@isuvax.iastate.edu writes: > I am currently working on a project, and am looking for examples of how to > parse prolog efficently (preferably using c or yacc code). You cannot parse Prolog using Yacc, because Prolog is not an LR(1) language. It is possible to construct a Prolog term of any desired length such that the interpretation of the first token (atom? prefix op?) cannot be determinee until the last token has been seen, which means that Prolog is not LR(k) or LL(k) for _any_ k. It is, however, fairly straightforward to parse Prolog _in_ Prolog. READ.PL is available in the DEC-10 Prolog library. > Could anyone > direct me to sites with FTP-able prolog source code, and/or books > documenting how to create prolog parsers (I have noticed that many books > on begining prolog give a rudiementry sketch of the prolog heirarchy, but > they tend not to go into full detail) Thank you in advance. There is no such word as "heirarchy". The word is "hierarchy" (from "hieros" + "arkhe"; "sacred rule" or "priest rule"). I can't for the life of me think what "the Prolog hierarchy" might be. My book, "The Craft of Prolog", provides full Prolog source code for tokenising Prolog (an update for the file TOKENS.PL in the DEC-10 library), but not READ.PL. Get a copy of the DEC-10 Prolog library from the University of Edinburgh. -- Bad things happen periodically, and they're going to happen to somebody. Why not you? -- John Allen Paulos.
raghutp@hubcap.clemson.edu (Raghu Toppur) (05/02/91)
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. It is possible to construct a Prolog term of any desired > length such that the interpretation of the first token (atom? prefix op?) > cannot be determinee until the last token has been seen, which means > that Prolog is not LR(k) or LL(k) for _any_ k. > 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) ? 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. -- Raghu Toppur e-mail : raghutp@hubcap.clemson.edu Dept of Comp Sc, Phone : 803-656-2637 Clemson University, Clemson, SC 29631.
brady@swift.cs.tcd.ie (05/06/91)
> -- > Bad things happen periodically, and they're going to happen to somebody. > Why not you? -- John Allen Paulos. What I really want to know is, where does Richard get his signatures from? Mike brady@cs.tcd.ie
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (05/08/91)
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 <beginning of term> ( [ { , | cannot have a left operand (so is not an infix or postfix operator) - a token preceding <end of term> ) ] } , | 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.