🚀 go-pugleaf

In article <7290@agate.BERKELEY.EDU> lagache@violet.berkeley.edu (Edouard Lagache) writes:
>     So what does this have to do with PROLOG?  Well, in PROLOG one often
>     finds value merging separate operations of a predicate to improve
>     efficiency.  For example, lets look at Clocksin and Mellish's two
>     codings of reverse.

...rev/2 and rev/3 example

>  However, I will say this: LISP is clearly well suited to a
>     "simple decomposition" view of programming.  For PROLOG to compete, it
>     will either have to provide enough efficient primitives to permit
>     reasonably simple decomposition of problems (even if such solutions are
>     not as optimal), or it will have to force programmers to de-empathizes
>     the value of simple decomposition as a paradigm for good programming
>     style.

Forgive me, but I don't see what this example has to do with the
"simple decomposition" view of programming (doesn't sound like a new
idea to me :-).  The optimisation of naive reverse (an order
n-squared procedure) to the normal reverse (order n) is a
straightforward example of program transformation in the interests of
efficiency.  Another of the standard transformations is the merging
of two loop operations into a loop, though as it happens this isn't
an example.

Now there are lots of researchers beavering away round the world to
produce systems that do this automatically. What they ARE agreed
about is that it's much easier to do all the hard work in a pure
declarative language. Whether that is pure Lisp or pure Prolog
doesn't seem nearly so important. For the record there are people
(e.g at Imperial:  Chris Hogger) who are doing this in Prolog.

Chris Moss.