Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!sdd.hp.com!news.cs.indiana.edu!ariel.unm.edu!nmsu!opus!ted From: ted@nmsu.edu (Ted Dunning) Newsgroups: comp.lang.prolog Subject: Re: "Embedded Prolog" in C code Message-ID: Date: 31 May 91 17:30:41 GMT References: <1991May26.231138.13000@brolga.cc.uq.oz.au> <644@fudd.dataco.UUCP> <653@fudd.dataco.UUCP> Sender: news@NMSU.Edu Organization: Computing Research Lab Lines: 89 In-reply-to: campbell@dataco.UUCP's message of 30 May 91 20:12:22 GMT In article <653@fudd.dataco.UUCP> campbell@dataco.UUCP (Duncan Campbell) writes: Well, Ted, out here in the real world _REAL_ Prolog isn't much use to anyone. indeed. i would have gathered otherwise from the literature that vendors send me about all the real applications that their customers have written. i would have gathered otherwise from the real applications that i currently support. Indeed, if I were required to use a "pure" language, I simply would not bother with prolog at all: Scheme _IS_ a far superior language. of course, scheme isn't a pure language. at least not in the customary sense of not allowing assignments. The fact remains that PDCProlog provides much of the functionality of "pure" Prolog and possesess the features like timers, static typing and execution speed (*10 faster than "pure" prolog) needed for real-time applications. timers? no problem to add to any of the prologs i use (quintus, sicstus). in fact, i did it just last month. static typing? do you required required static typing that won't allow you to declare all the legal values in the language? well, then you really do want to have turbo instead of the real thing. if, on the other hand, you want inferred typing, or compile time type checking then you should check out peter van roy's latest compiler or the mycroft and o'keefe type checker. execution speed? where do you get these numbers? last i checked (which was some time ago) als prolog ran on pc's and macs and produced code which ran just about even with turbo prolog. peter van roy's compiler produces code which runs even with compiled and optimized c code. i would have to admit that there is _some_ prolog that runs at least 10* slower than turbo prolog. in fact, i could write you one. ok... since turbo prolog is prolog, let's see somebody write the following predicates: 1) a standard findall. 2) a variation on the standard dcg expansion which allows me to write in a functional style and which translates all calls to :=/2 so that the left hand side is unified with the functional result of the right hand side. this should integrate into the normal compilation process so that you don't have to worry about preprocessing your files. 3) a weakening of the above where instead of adding to the standard clause expansion, you just write a wrapper around predicate that compiles files. it should cause the files to be preprocessed, then compiled and loaded. 4) a rewrite of the following predicate: forall(G, P) :- \+ (G, \+ P). that does not include an entire interpreter for prolog. 5) a simple program that takes as an argument a goal written in a syntactic variation of prolog, and then executes it. ================================================================ as a preview of the problems you are likely to have with turbo prolog, 1) woops... you can't declare a type for a general term. nor can you call a variable. 2) oh, golly, term expansion is built in and can't be changed. 3) darn, i have to write a new version of read which will read standard terms and give me decorated terms. then the translator isn't too hard. except that it can't dynamically check to determine which predicates are defined. 4) darn, no passing goals as arguments 5) woops... can't declare the type for the argument, nor can i call the result even if i did manage to translate it. oh well, i can always write a prolog interpreter to make this look like it works.