From mboxrd@z Thu Jan 1 00:00:00 1970
Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail
From: Philipp Stephani
Newsgroups: gmane.emacs.devel
Subject: Re: [PATCH 2/2] Add module functions to convert from and to big
integers.
Date: Tue, 23 Apr 2019 17:54:37 +0200
Message-ID:
References: <20190423131742.65814-1-phst@google.com>
<20190423131742.65814-2-phst@google.com>
<102dc3dc-554c-a55e-ae7c-cc7357ee60f5@cs.ucla.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226";
logging-data="187959"; mail-complaints-to="usenet@blaine.gmane.org"
Cc: Philipp Stephani , Emacs developers
To: Paul Eggert
Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 23 17:55:47 2019
Return-path:
Envelope-to: ged-emacs-devel@m.gmane.org
Original-Received: from lists.gnu.org ([209.51.188.17])
by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256)
(Exim 4.89)
(envelope-from )
id 1hIxlq-000mj6-Ee
for ged-emacs-devel@m.gmane.org; Tue, 23 Apr 2019 17:55:46 +0200
Original-Received: from localhost ([127.0.0.1]:55804 helo=lists.gnu.org)
by lists.gnu.org with esmtp (Exim 4.71)
(envelope-from )
id 1hIxlp-0002I2-Gl
for ged-emacs-devel@m.gmane.org; Tue, 23 Apr 2019 11:55:45 -0400
Original-Received: from eggs.gnu.org ([209.51.188.92]:39705)
by lists.gnu.org with esmtp (Exim 4.71)
(envelope-from ) id 1hIxkx-0002Gj-Px
for emacs-devel@gnu.org; Tue, 23 Apr 2019 11:54:52 -0400
Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from ) id 1hIxkw-0008Oi-Cg
for emacs-devel@gnu.org; Tue, 23 Apr 2019 11:54:51 -0400
Original-Received: from mail-oi1-x243.google.com ([2607:f8b0:4864:20::243]:43068)
by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16)
(Exim 4.71) (envelope-from )
id 1hIxkw-0008OL-7e
for emacs-devel@gnu.org; Tue, 23 Apr 2019 11:54:50 -0400
Original-Received: by mail-oi1-x243.google.com with SMTP id t81so11671772oig.10
for ; Tue, 23 Apr 2019 08:54:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=Wi2nGQcTKKZD4vf+PVkKlro2uODR0yaiH3cx9GlDHh8=;
b=ZSZBVf31pUXAPwShSJFp/i8fZq6tbG7/n3ZYWvoteYby3d8iAToGHeINfEQS77uqUo
rWGSBQxmWYx2l3u12fnSRnISa3s+8y3tacxKzY6lKC0MoVze9qWPfLiVRQ+BrbFQtK5P
6XYiId4Bi87Bx+aubTqZPu02rw+q9qQgZjEXk5nLQ/gh8yUC/UzGKK6UEwDBj52W/WEg
kU3H+PzbnVmtaGKx3c0p9ttiPxH7LbGMRB5Dn2ejhNaNIxbKfZp4GZAFytQnqOUzcPXG
Gz5pR1q6fguBxp1KfqbzGCPktTrm6YGR83KsSBj3lHvlv74SrDAkiEma2V7mnOkvahSg
iaFQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=Wi2nGQcTKKZD4vf+PVkKlro2uODR0yaiH3cx9GlDHh8=;
b=AAJR2NPVo33DeTR8gZa/c6gPlJStMs5sF/C8qZmTsEkLWrZsS74LTmJZVDbH+u1R2W
kJOUzbbpAW0qftvMqrEY4wNsETGcA6wwk18R/+N1stLn0NEthf1Td9CBoMs6vAEZ334v
uv/FWuBiGM/NuRl8PcZsWcuXfpWjayN9Ue2NHXTvBicrhraUDHRF8INHWoBFotimXTKw
4iA35CxE2mcwqi0spQ7ghxlXf/ld4on2q9d+rvCXf/Wocd0MJB66YyHu6yJrWyAKysGL
cXzVOnjrFu+kbIhtC3wLo5Q0eB2wTEv28ZjAH6r/fohj7LrX42pp55UY7hvGheGkMDD1
FeFQ==
X-Gm-Message-State: APjAAAVkKupQJbMynZk3SjS/ZTNPHQnpyf4ICLLIIRx4oHmhfC30roD9
sLwZWMMRsqek8yPzVPlw9SS/EuvLjG50yVFpuso=
X-Google-Smtp-Source: APXvYqxvGkPo0c3IsLDXFdgMEknBIng2MWUo5pRBeGFv7P6Ja3LYaKClMfAtgF+0i8PAx+6ZaosKpAlqvbDHhgmUzgs=
X-Received: by 2002:aca:d90a:: with SMTP id q10mr2306841oig.65.1556034888664;
Tue, 23 Apr 2019 08:54:48 -0700 (PDT)
In-Reply-To:
X-detected-operating-system: by eggs.gnu.org: Genre and OS details not
recognized.
X-Received-From: 2607:f8b0:4864:20::243
X-BeenThere: emacs-devel@gnu.org
X-Mailman-Version: 2.1.21
Precedence: list
List-Id: "Emacs development discussions."
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org
Original-Sender: "Emacs-devel"
Xref: news.gmane.org gmane.emacs.devel:235827
Archived-At:
Am Di., 23. Apr. 2019 um 17:48 Uhr schrieb 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).
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.