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: Oddities with dynamic modules
Date: Thu, 21 Mar 2019 21:12:05 +0100
Message-ID:
References: <83y3b4wdw9.fsf@gnu.org>
<83tvhal45r.fsf@gnu.org>
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="229075"; mail-complaints-to="usenet@blaine.gmane.org"
Cc: Emacs developers
To: Eli Zaretskii
Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 21 21:14:21 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 1h744y-000xT7-VI
for ged-emacs-devel@m.gmane.org; Thu, 21 Mar 2019 21:14:21 +0100
Original-Received: from localhost ([127.0.0.1]:46217 helo=lists.gnu.org)
by lists.gnu.org with esmtp (Exim 4.71)
(envelope-from )
id 1h744x-0008S8-QJ
for ged-emacs-devel@m.gmane.org; Thu, 21 Mar 2019 16:14:19 -0400
Original-Received: from eggs.gnu.org ([209.51.188.92]:38422)
by lists.gnu.org with esmtp (Exim 4.71)
(envelope-from ) id 1h7435-0007o5-0O
for emacs-devel@gnu.org; Thu, 21 Mar 2019 16:12:24 -0400
Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from ) id 1h7433-0002WL-MJ
for emacs-devel@gnu.org; Thu, 21 Mar 2019 16:12:22 -0400
Original-Received: from mail-ot1-x334.google.com ([2607:f8b0:4864:20::334]:45254)
by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16)
(Exim 4.71) (envelope-from )
id 1h7430-0002RP-2Q; Thu, 21 Mar 2019 16:12:18 -0400
Original-Received: by mail-ot1-x334.google.com with SMTP id e5so5605019otk.12;
Thu, 21 Mar 2019 13:12:18 -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=jjTRmSrdT1ji6TfQ/kY/CCY7rZis3EIoaoOHFqoKEDQ=;
b=r6k/ro7u7MwpWHv/H/xlh1GKK2ZziTu9rXEjhuFKZoOvYamxcxzMNQO7zimcSu1Eda
w6qacV32ibCh/soo6amsoGneVaOAiHLch4hrv3adI3qNIP54c2KC8Xub473HrNtTay5F
Mk/tfrd64GVHcesXpoZhdD6mvO48iNLn8mXrUbXy2+h2O9xzw+euYAIVprlTMSEsBxDX
aWK8vceAPXkLa7nBf8Rd7qL/7Llz8iD1orgIFJ4UawSJvWAUbp+j3CNoXKtpHpkeOV+H
GpcHRnVlEnDqQT0UYzuP7gRHyEn3C6/4VrbjiAYmyXTGjG8ZIPHG9AK4fAdpkUQTYIpS
QjvA==
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=jjTRmSrdT1ji6TfQ/kY/CCY7rZis3EIoaoOHFqoKEDQ=;
b=b+8bCoiCYhjT2ORkmxSQe2CgXWdhGCDgdi3MLfLQhyYVFgJ6uvQ7ECZlAcFsRMtTfg
uItw9DzFQnbydNHBtISNRPAphkc4JTU+lBy2f98nYfUmBE5jJeMdh6UuoFn9O4MClfFE
CkeWylvm/4nrjUW/5ouoR8tv7Hwk1hVCyexEzFkoWvOJBo7ALdtPk+OzFinq3m/U1+pk
XSXO9ou5njZ/uff434+3pUPLOUsWInxV3BYNH8nFXIHVmrwQGacoFLoFZ0DkVsQT4pGQ
a13Wm4V2621rmkQkY2A5gZAMz6u/0yjDDpdulit1Wx12xFItEHV3OH+4w9ZlTyFtxISH
zhag==
X-Gm-Message-State: APjAAAULuCIeSD/69oyugjbMROZEdKhspSt4lBcTVTca3vMfwQuKm3Ul
prTbXntgfnk6o/OobTlV+YQLbt1ooSoqCBehlE/7lCd8
X-Google-Smtp-Source: APXvYqz7+BRRmE/ljpY4fHhzYjC3XBiuleHw6d7D4z6SBR4b/ckE1eEYrtKy1O3vZlpVd7A1Vpp778aHskj81NW+p1Y=
X-Received: by 2002:a9d:62c8:: with SMTP id z8mr3965690otk.144.1553199136855;
Thu, 21 Mar 2019 13:12:16 -0700 (PDT)
In-Reply-To: <83tvhal45r.fsf@gnu.org>
X-detected-operating-system: by eggs.gnu.org: Genre and OS details not
recognized.
X-Received-From: 2607:f8b0:4864:20::334
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:234479
Archived-At:
Am Mo., 11. Feb. 2019 um 16:46 Uhr schrieb Eli Zaretskii :
>
> > From: Philipp Stephani
> > Date: Sun, 10 Feb 2019 21:23:18 +0100
> > Cc: Emacs developers
> >
> > > . Using 'funcall' is unnecessarily cumbersome, because the function
> > > to be called is passed as an 'emacs_value'. Why don't we have a
> > > variant that just accepts a name of a Lisp-callable function as a C
> > > string?
> >
> > Convenience is not a design goal of the module API. The primary design
> > goals are robustness, stability, simplicity, and minimalism.
>
> I thought simplicity and convenience of use tramps simplicity of the
> implementation, so it is strange to read arguments to the contrary.
Simplicity tends to be the opposite of convenience. Interface
simplicity definitely trumps convenience and implementation
simplicity.
>
> > > . Why does 'intern' only handle pure ASCII symbol names? It's not
> > > like supporting non-ASCII names is hard.
> >
> > Unfortunately it is, due to Emacs underspecifying encoding. If we can
> > manage to write an 'intern' function that accepts UTF-8 strings and
> > only UTF-8 strings, I'm all for it.
>
> What are the problems you have in mind? After all, this is already
> possible by means of 2 more function calls, as the example in the
> manual shows. Are there any problems to do the same under the hood,
> instead of requiring users to do that explicitly in their module code?
If users want to have a truly generic "intern" function, they need to
do some legwork anyway because the signature of the "intern"
environment function doesn't allow embedded null bytes. It's also
unclear how non-Unicode symbols should be represented (if at all).
Given that almost all uses of "intern" will use ASCII symbols, it's
fine to restrict the API in this way. I've provided an example for a
wrapper function that allows at least interning of arbitrary Unicode
strings: https://phst.eu/emacs-modules#intern.
>
> > > . I could understand why equality predicates are not provided in the
> > > API, but I don't understand why we do provide 'eq' there. Is it
> > > that much more important than the other predicates?
> >
> > Yes, it represents a fundamental property of objects.
>
> How is that relevant? Equality predicates are used very frequently
> when dealing with Lisp objects; 'eq' is not different from others in
> that respect.
I don't recollect the reasoning, but Daniel stated that "eq" is
strictly necessary, so you might want to ask him.
>
> > > IOW, if the API was supposed to be minimal, it looks like it isn't;
> > > and if it wasn't supposed to be minimal, then some important/popular
> > > functions are strangely missing, for reasons I couldn't wrap my head
> > > around.
> >
> > It is *mostly* minimal. A *completely* minimal API would not even have
> > integer and floating-point conversion functions, as those can be
> > written using the string functions. But that would be far less simple
> > and robust.
> > "eq" and "is_not_nil" are special in that they implement access to
> > fundamental object properties and can't fail, so they are fundamental
> > enough to deserve an entry in the module table.
>
> I cannot follow this reasoning, sorry. It sounds like you are saying
> that the decision what to implement and what not justifies itself
> because it's there. All I can say is that as someone who wrote a
> couple of lines of code in Emacs, the stuff that is in the API and the
> omissions look quite arbitrary to me.
Please see Daniel's original reasoning for the design. I'm not
claiming perfection for the module API, but it definitely strikes a
very good balance between minimalism and robustness.
>
> > The best source to answer the "why" questions is still the original
> > design document:
> > https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00960.html
>
> Which part(s) of that long document answer these questions, please?
Mostly the first sentence "We want an ABI powerful enough to let C
modules interact with Emacs, but decoupled enough to let the Emacs
core evolve independently."