Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!cornell!uw-beaver!teknowledge-vaxc!sri-unix!quintus!ok From: ok@quintus.uucp (Richard A. O'Keefe) Newsgroups: comp.lang.prolog Subject: Re: Pascal/C -vs- Prolog Message-ID: <288@quintus.UUCP> Date: 14 Aug 88 01:30:48 GMT References: <184@quintus.UUCP> <607@ecrcvax.UUCP> <247@quintus.UUCP> <614@ecrcvax.UUCP> Sender: news@quintus.UUCP Reply-To: ok@quintus.UUCP (Richard A. O'Keefe) Organization: Quintus Computer Systems, Inc. Lines: 63 In article <614@ecrcvax.UUCP> micha@ecrcvax.UUCP (Micha Meier) writes: > I don't see your point - everybody can speed up his/her Prolog > system, independently on what compiler is being used. You are > saying "if I'm speeding up my compiler, user's code is speeded > up as well (as a side effect)". Well I don't need to speed > up my compiler, I can concentrate on speeding up the user's code. No, that is the direct opposite of what I am saying. What I am saying is that IF you improve the quality of the code that you generate, or the efficiency with which that code is executed, then *BOTH* the user's code *AND* the compiler speed up. Neither is a side effect: both are the very same primary effect. The point is that with a compiler written in Prolog the vendor has an _incentive_ to do things which will benefit the customer as well. >> ... This will speed up the user's code, >> and a well-written Prolog compiler will have quite a few tables, > > actually, a Prolog compiler does not need much more than 6 tables :-) No Prolog program needs more than one table: you can pack the entire program into a table of unit clauses and run an interpreter over it. Do you have some specific reason for quoting the number 6? > I cannot avoid noting that there are > quite a few Prolog compilers around, and their writers > probably have not followed your suggestions ( I can understand > it, what a challenging problem to write a Prolog compiler, > no matter how). I have no doubt that it is possible to write > a clean and relatively fast Prolog compiler, but is what > you suggest enough to achieve that? The only way is to try, > but is there anybody out there trying to write a *clean* > Prolog compiler? It's easier to do that in C, I'm afraid. Remember Sturgeon's law? "90% of _everything_ is crud". Why should Prolog compilers be an exception? There is something rather interesting here. I come from the "Edinburgh" culture. I believe that David Warren originally started to write the DEC-10 Prolog compiler in BCPL (maybe it was BLISS-10), and then switched over to Prolog because it was easier. I had a nodding acquaintance with the ML-in-ML compiler. What I am about to say is an expression of my feelings, not a reasoned argument. I feel safe and confident about writing compilers in "declarative" languages: if I had to write another Prolog compiler and didn't have Prolog to do it in I'd do it in ML, and if I couldn't get my hands on that I'd fall back on Lisp. I find the thought of writing a Prolog compiler in C almost frightening, it strikes me as so tedious, so unsafe, so clumsy. (C++, now, I might almost consider _that_.) I believe that the freedom to change data structures around is important for producing an efficient compiler, and it is very easy to do that in Prolog and quite hard in C (not so hard in C++). The idea that it could be considered easy to write a Prolog compiler in C is very strange to me. Evidently, I need to be instructed. I understand that ECRC is no more in the business of giving things away free to strangers than Quintus is, but is there anything written up about how to write Prolog compilers in C? How do you execute bits of the source code at compile time? [Tokenisers for Prolog in C, I understand. Parsers for Prolog in C, I understand. Peephole optimisers and assemblers for WAM instructions in C, I understand. It's the bit in the middle I need to have explained. ]