🚀 go-pugleaf

In article <5005@utah-cs.UUCP>, shebs@utah-cs.UUCP (Stanley Shebs) writes:

> I would like ... to see cuts disappear from implementations entirely,
> to be replaced by meta-level capabilities, but I suppose that's a
> forlorn hope, since everybody wants "efficiency".

You can't fault people for wanting efficiency.  You *can*, however, fault
implementations that rely overmuch on cuts for performance (I guess most
current implementations would end up being faulted: for example, how many
commercial Prolog systems out there would recognize that, given the mode
<+,+,-,-> for the predicate

	part([],_,[],[]).
	part([E|L], M, [E|U1], U2) :- E =< M, part(L,M,U1,U2).
	part([E|L], M, U1, [E|U2]) :- E  > M, part(L,M,U1,U2).

there's no need to create choice points for it?  None that I'm aware
of! [*]).  Hopefully, as compilers improve, cuts will become less
essential for good performance.

Talking about implementations, I was quite surprised to see, at SLP 87
earlier this month, at least two high-powered commercial Prolog systems
suffer a factor of 3 slowdown when I changed append/3 from

	append([],L,L).
	append([H|L1], L2, [H|L3]) :- append(L1, L2, L3).
to
	append([],L,L).
	append([H|L1], L2, L) :- L = [H|L3], append(L1, L2, L3).

Their performance, on naive reverse on a Sun-3/75, dropped from about
140 KLIPS for the "usual" append to about 40 KLIPS for my "mutant"
append.  You think people would do a better job of handling 
inline predicates and temporaries!
-----
[*] Some versions of SB-Prolog recognize that no choice point need be
created in this case.  Of course, SB-Prolog isn't a commercial system.
-----
-- 
Saumya Debray		CS Department, University of Arizona, Tucson

     internet:   debray@arizona.edu
     uucp:       {allegra, cmcl2, ihnp4} !arizona!debray