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

[Philipp Stephani]

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.

>
> Could emacs-module.h expose to the user a GMP-style interface only if
> the macro __GNU_MP_VERSION is defined? (Or we can choose our own macro
> name if we don't want to require the user to include gmp.h before
> emacs-module.h.) That way, users that don't use big integers won't need
> to worry about GMP at all.

This is possible (and indeed required) since we couldn't require GMP
headers unconditionally.
My current approach would be to define a new macro EMACS_MODULE_GMP
and wrap the mpz_t type in a datatype like this:

#ifdef EMACS_MODULE_GMP
struct emacs_mpz { mpz_t value; };
#else
struct emacs_mpz;
#endif

We always need to expose the conversion function, that's required for
ABI compatibility. However, using the approach with a forward-declared
struct (that is never defined) would prevent users that don't have GMP
from using the API.

I'm generally fine with that approach as well.