🚀 go-pugleaf

In article <1389@quintus.UUCP>, dave@quintus.UUCP (David Bowen) writes:
[ in response to my statement that Robin Popplestone is *RIGHT* that
  correct integer arithmetic is a Good Thing, and my further claim that
  correct integer arithmetic ought to be in the Prolog standard.
]
> arguments could be made.  Two questions are:  how long do we want to go on
> debating/specifying all these extra features, and how much burden do we want to
> put on implementors.

I have also received E-mail in which I was asked
    Indeed [bignums are in Lisp, Haskell, and so on], but [it is]
    hard to find a public and portable implementation of bignums that
    I can use in my own scheme for example.  Any ideas ??

As it happens, I have sources for more Scheme systems than I know what
to do with.  One of them is ELK.  Here is the file ORIGIN from the
source distribution of ELK 1.0.

    This software is Copyright 1987, 1988, 1989, Nixdorf Computer AG
    and Teles GmbH, Berlin.

    This software has been written by Oliver Laumann (me) for TELES
    Telematic Services, Berlin, in a joint project between TELES and
    Nixdorf Microprocessor Engineering, Berlin.  I would like to thank
    Claus Bathe of NME Berlin for securing the permission from his
    management to publish this software, Prof. Dr. Sigram Schindler for
    providing the work environment for ISOTEXT and Elk, and Carsten
    Bormann for his support and src/bignum.c.
				^^^^^^^^^^^^
    Any use of this software is permitted provided that this notice is not
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    removed and that neither Oliver Laumann nor TELES nor Nixdorf are
    deemed to have made any representations as to the suitability of this
    software for any purpose nor are held responsible for any defects of
    this software.  THERE IS ABSOLUTELY NO WARRANTY FOR THIS SOFTWARE.

    Berlin, July 1, 1989

    Oliver Laumann              net@TUB.BITNET              net@tub.UUCP

That's not the only bignum package I have, but it's the one with the least
restrictive copyright.  (Oaklisp is covered by a GNU-style "copyleft", and
I've not got that on-line.)  elk/src/bignum.c is about 660 lines of fairly
clear well-laid-out C code.  If the extra functions needed for Prolog
(mainly the bitwise operations) were added, and some of the ELK-specific
stuff were stripped out, it might come to 700 lines.

I would of course be reluctant to suggest enlarging PC Prologs, but for
one fact:  the major limitation on the ones I know about is not the size
of the support code, but the size of the Prolog stacks.  By allowing
bignum arithmetic to be implemented at a lower level than library(long)
and perhaps even allowing bignum bodies to be stored in another stack
entirely, bignum support would mean that PC Prologs could handle BIGGER
problems than they now can by using library(long).  And the code is
ALREADY available at the price of an acknowledgement!  (At least one of
the PC Prologs I know about currently switches from one representation
to another when the 16-bit limit is reached _anyway_, the snag is that
they switch to float and start producing wrong answers...)

-- 
"private morality" is an oxymoron, like "peaceful war".