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.