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

[Eli Zaretskii <eliz@gnu.org>]

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Wed, 24 Apr 2019 19:15:13 +0200
> Cc: Paul Eggert <eggert@cs.ucla.edu>, Emacs developers <emacs-devel@gnu.org>, 
> 	Philipp Stephani <phst@google.com>
> 
> > > 1. Don't support these functions at all if GMP isn't available (i.e.
> > > signal an error unconditionally)
> > > 2. Add another preprocessor macro that would stop emacs-module.h from
> > > including gmp.h.
> > >
> > > (1) seems a bit easier and cleaner, but means that we wouldn't support
> > > these functions if Emacs isn't compiled with GMP support.
> >
> > I don't think I understand (2): how would you declare GMP-related data
> > types used in emacs-module.c, if you don't include gmp.h?
> 
> It would require the user (or rather, Emacs) to include gmp.h or
> mini-gmp.h before including emacs-module.h. I.e.:
> 
> #ifndef EMACS_MODULE_DO_NOT_INCLUDE_GMP_H
> #include <gmp.h>
> #endif

Ah, okay.  But then what would emacs-module.c do with these 2 new APIs
if gmp.h was not included?

> > And there might be option (3): have emacs-module.h duplicate the
> > portion of mini-gmp.h that are needed when gmp.h isn't available.
> > It's a bit inelegant, and maintenance burden, but maybe not grave
> > enough to decide that wer cannot support bignums without a real GMP.
> 
> I don't think we should replicate internal data structures of
> third-party libraries. It's really ugly.

mini-gmp.h is not third-party, it's Emacs.

The problem I'm struggling with is how can we defend lack of support
of bignums in modules when Emacs itself does support them?