[comp.lang.prolog] PROLOG Digest V5 #69

PROLOG-REQUEST@SUSHI.STANFORD.EDU (Chuck Restivo, The Moderator) (09/29/87)

PROLOG Digest           Wednesday, 30 Sep 1987     Volume 5 : Issue 69

Today's Topics:
                           Query - HP 9000,
                 Implementation - Erratum & Standards
----------------------------------------------------------------------

Date: 28 Sep 87 17:51:13 GMT
From: Anne Louise Gockel <vax1!ag4@cu-arpa.cs.cornell.edu>  
Subject: CProlog for a HP 9000 running HP-UX

I am naively trying to compile CProlog 1.5 on the Hewlett-Packard HP
9000 which runs HP-UX.  HP-UX is a System V based Unix. The HP-UX C
compiler chokes on several constructions that the Mt. Xinu (BSD)
C-compiler allows.

Can anyone tell me where I can find a CProlog that will compile on a
System V machine, or even better under HP-UX?  Can anyone tell me
where I can find a more recent version of CProlog?

I am not sure why the BSD C compiler compiles the code that the HP-UX
compiler chokes on.  As far as I can see the code is incorrect.
Basically a variable that is defined as 'pointer to a pointer' is
dereferenced.  E.G.:

/* The original EMAS Prolog in IMP relies too much on pointers being
   just addresses, independently of the type pointed to, for me to be
   able to do anything about it. To help satisfy the compiler's view
   of typing, addresses are objects of type PTR, which are then cast
   into the appopriate types.
*/
typedef unsigned **PTR;
static  PTR f, d, b, k, k1, y, p, l, arg1;
 .......
        if (k->NextVar == NULL ||
            (SC(k->NextVar,>=,pauxstk) && SC(k->NextVar,<,ptr))) {
            k->VarValue += rglb;
            if (k->NextVar) k->NextVar += rauxstk;
            k += k->VarLen;
        }

In the above code fragment the compiler complains about dereferencing
the variable k.  ('Cannot select field of non-structure.' and
'Incompatible types in cast.') SC is a macro that does a
signed-comparison between the 1st and 3rd arguements.

Thank you.
-- Anne Louise Gockel

------------------------------

Date: Mon, 28 Sep 87 14:04:16 PDT
From: Richard A. O'Keefe <quintus!cresswell!ok@Sun.COM> 
Subject: Erratum

The "call/N" message I sent was automatically reformatted somewhere
along the way.  Amongst other things, this caused the loss of a line.

"I am assuming here a conventional Prolog rather than a sound
implementation"

should read

"I am assuming here a conventional Prolog rather than a
sound implementation OF HIGHER-ORDER LOGIC".

This was followed by

"The public-domain parser held at Stanford in the files
        TOKENS.PL
        READ.PL"
...

Yes, there is a public-domain parser which is 99.9% compatible with
DEC-10 Prolog.  All you need is get0/1, name/2, and (functor/3 and
arg/3 or (=..)/2), and away you go!

------------------------------

Date: 29 Sep 87 03:31:47 GMT
From: Saumya Debray <debray@arizona.edu>
Subject: Standard of code

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

------------------------------

End of PROLOG Digest
********************