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

[Paul Eggert]

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).

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.

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.

It might also be good (independently of having a GMP-style interface) to
expose just mp_limb_t to module code - we could give it another name and
put it into emacs-module.h as "typedef XXX bignum_limb_t;" where XXX is
either unsigned int, unsigned long int, or unsigned long long int, as
computed by 'configure'. This could avoid much of the overhead of
converting between GMP's representation and the unsigned char
representation.