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.
]