Re: integer overflow

[David Kastrup <dak@gnu.org>]

"Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp> writes:

> David Kastrup writes:
>  > Richard Stallman <rms@gnu.org> writes:
>  > 
>  > > I have heard that Guile now supports Emacs Lisp.  And it has bignums.
>  > > So if we make Emacs use Guile, that will automatically provide
>  > > bignums.
>  > 
>  > My first reaction to that would be "Whoa, whoa, whoa!".
>  > 
>  > The second that "librep" might be an easier starting point for migrating
>  > the Lisp engine.
>
> For bignums, XEmacs or SXEmacs might be easier yet.

But the "Whoa" factor is lost.

> The work of integrating bignums (GNU MP and BSD MP are both supported
> as compile-time options) was done by Jerry James.  He is probably
> *not* available any time soon (his day job just turned into a
> day-and-night job) but the pedigree of the code is easily established
> and he and other contributors probably would be willing to sign
> papers.

[...]

> However, this is all kind of irrelevant.  Using bignums as pure
> numbers is relatively easy.  The hard part is introducing them as
> numerical components of internal Emacs structures (buffer size and
> positions, markers, overlays, text properties), and integrating them
> with niceties like (system-dependent) large file support, etc.  This
> is in no way an automatic consequence of language support for bignums.

IIRC, this has not been done in the bignum integration of XEmacs and its
ilk.  So there is not much code worth the taking.

Transparent bignums should indeed be easy to do: just check the overflow
of integer arithmetic operations and behave accordingly.  Arithmetic now
catering for float and integer would have to cater for bignums as well.

Anyway, I guess that Richard's point more or less was that Emacs' Lisp
engine was worth substituting, and that such a radical move might solve
unrelated problems as well.

bignum support alone indeed should be reasonably straightforward.  It
should certainly speed up Emacs calc once Emacs calc is cleaned up to
use it.

-- 
David Kastrup