Re: [PATCH 2/2] Add module functions to convert from and to big integers.

[Philipp Stephani]

Am Di., 23. Apr. 2019 um 17:54 Uhr schrieb Philipp Stephani
<address@hidden>:
>
> Am Di., 23. Apr. 2019 um 17:48 Uhr schrieb Paul Eggert <address@hidden>:
> >
> > On 4/23/19 8:12 AM, Philipp Stephani wrote:
> > > I considered using GMP. However, it has quite a few downsides:
> > > - It would require making emacs-module.h dependent on GMP, even for
> > > users that don't use big integers. Right now it only depends on
> > > standard C, and I'd like to keep it that way.
> > > - It's unclear how well GMP is supported in other languages. mpz_t is
> > > a weird and unusual type, and other languages might not support it
> > > well in their C interface.
> > > - Other languages tend to have their own bigint support, so I don't
> > > think the advantages of using GMP directly are that big.
> >
> > All true, though Emacs requires GMP anyway (one way or another) and it's
> > typically faster than the non-GMP approaches used in Python (and I
> > assume elsewhere).
>
> Emacs does require GMP, but module authors might not.
>
> >
> > Some of this depends on the importance of performance and convenience
> > when communicating between Emacs Lisp and GMP-using modules. If these
> > are unimportant then the current approach is OK. However, I'm thinking
> > that at least some users will view them as being important.
>
> They are definitely not unimportant, though less important than
> robustness and simplicity.
> OTOH, the proposed approach isn't really simpler or more robust
> either. It's just less dependent on third-party libraries.

After gaining a bit of experience with the current implementation
(including writing bindings for Go), I'm now again convinced that we
should take the original approach (only relying on the C standard and
not introducing an optional dependency on GMP).

- It feels generally wrong and too heavyweight to introduce a
dependency on a third-party library just to represent what is
essentially a byte array plus a sign bit.

- The current implementation requires module authors to depend on
exactly the same GMP library as Emacs, because otherwise the
allocation functions aren't compatible. In particular, module authors
can't statically link GMP.

- Many programming languages such as Go, Java, or Python have big
integer support built into the language or the standard library. They
don't gain anything from using GMP in the module interface.

- The interface leaks an implementation detail of Emacs to the module
interface. Even if Emacs were to switch away from GMP at some point,
it would still have to support the GMP interface and link against GMP.

- Using conditional compilation means that the header isn't hermetic
any more. This can produce surprising results (compilation now depends
on whether some other header has already included emacs-module.h, with
potentially other preprocessor macros), and breaks things like
precompiled headers.

The primary advantages of using GMP in the interface are:

- C and C++ module authors that use GMP anyway benefit from a bit
easier interface. I don't think this argument is very strong, as
writing the necessary glue code using mpz_import and mpz_export isn't
too onerous and can easily be factored out.

- Not calling mpz_export/mpz_import is a bit faster. This seems like
premature optimization to me, but we can even avoid that overhead by
using an unsigned long array for the magnitude: then GMP will
special-case the export/import to a memcpy (in the typical case where
the GMP limb is itself an unsigned long).

Overall I now think the original approach (without mpz_t) is quite
superior, and unless I hear convincing counterarguments, I'll send a
patch to revert to that.