🚀 go-pugleaf

Agreed that the elimination of syscall would be nice, and that there are
problems doing it.  However, the new versions only use syscall for the socket
code.  This implies that 'access', which used to be done through syscall no
longer need it.  Thus, as long as you are not using sockets, porting SBprolog
can be done by adding the following line in any .c file:

	syscall() { fprintf(stderr,"\nsyscall called -- error\n"); }

(or some such).

Now if it only had a real GC'er!

- mike

ps: explanation of the last comment : after years maintaining a
version of C-Prolog, which we used to write a 370 Prolog compiler (not
available -- we dont have a 370 anymore) that obtained about 1M lip,
and lately using SB-prolog, i've come to believe that no Prolog is
complete until it has a GC'er.  

When our prolog had a GC'er added, it could suddenly compile itself,
and be used for other 'big' or 'real' jobs, making it 'more useful'
than C-Prolog and SB-prolog even thought it used 24 bit (16M)
addressing.  Before that, even though it was very fast, ours was not as
'useful', because, though C-Prolog and SB-prolog also could not GC, they
had a much larger address space.

(I've been looking into getting SICStus just for the GC'er, but as my advisor
is broke, i'd have to pay for it myself!)