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: Sun, 10 Feb 2019 21:23:18 +0100
Message-ID:
References: <83y3b4wdw9.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="183321"; 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 Sun Feb 10 21:26:38 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 1gsvgS-000lZD-Lj
for ged-emacs-devel@m.gmane.org; Sun, 10 Feb 2019 21:26:36 +0100
Original-Received: from localhost ([127.0.0.1]:35188 helo=lists.gnu.org)
by lists.gnu.org with esmtp (Exim 4.71)
(envelope-from )
id 1gsvgR-0000Iw-J1
for ged-emacs-devel@m.gmane.org; Sun, 10 Feb 2019 15:26:35 -0500
Original-Received: from eggs.gnu.org ([209.51.188.92]:44206)
by lists.gnu.org with esmtp (Exim 4.71)
(envelope-from ) id 1gsvdo-0006HU-4K
for emacs-devel@gnu.org; Sun, 10 Feb 2019 15:23:53 -0500
Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from ) id 1gsvdi-0001z0-8w
for emacs-devel@gnu.org; Sun, 10 Feb 2019 15:23:50 -0500
Original-Received: from mail-ot1-x32f.google.com ([2607:f8b0:4864:20::32f]:33171)
by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16)
(Exim 4.71) (envelope-from )
id 1gsvdT-0001s3-Ih; Sun, 10 Feb 2019 15:23:31 -0500
Original-Received: by mail-ot1-x32f.google.com with SMTP id i20so14320093otl.0;
Sun, 10 Feb 2019 12:23:30 -0800 (PST)
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=PG86P3WwDx79SXDrHrLSd3EFfWiReMW5L63onPQqUds=;
b=rDb7aArux2dYBRUlKtjNGHxmBZj+2My0g/FyjbirsSpMnutD048mtCNLbZRKNbPl7T
wfR5su2ViIQJPmV4BUdJklQaurUakZ7XCeuT+9DX2y17SzofvNZRPZA5m3X0yr8Sk+uZ
7CTSUjyEaA2IKD15Uhlpqok3tlOrMnsWg+FQm8iJZ4vTlnYzs2qCJW73UHa/0yS9Qw/M
crw6TzweVGvkCqa7sfnUACHIz/eACdKAdoOnWgEP4UE1+FROsNQ/vLQJZ/eCSk434SAc
Q02HhMM+eomhIPwL2gEt/12/F5dyhf6djuzIJCUlLb5jStrBnfoHc1a5OCg/8Cb/y9OB
1Niw==
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=PG86P3WwDx79SXDrHrLSd3EFfWiReMW5L63onPQqUds=;
b=VlkQxjqhjbQopo90pXlYwUYD1DByawVTkFHl1IV7N/E4fzT9aCymYepxrv1r7EqugN
iD2vHII7X7jEDrYGlklsdDesWQPiiQF8E44ijmXx8C5ARTBKK+dDMDw81blX+UCkDblv
TbJ/WZRGQbEjI+i3gtm8Kw+3oqS3YcthAtFhqwXynC8zK3+AunVQQUGjsPwnW4Wc1fO8
yXPNb1Wl3oKndAOagw9GAowF9/bsBeD/BT21GSY5HUtLMRAXsxWeXfZHXEVj+259E5R0
3qTvEnwGBQ3a+JOh8qkR+PGlWYgTRp2m/3iW65pOtqIcwK/qNi2/Ai/N7Ujl3Kw+wKRB
FJ4g==
X-Gm-Message-State: AHQUAuaeeq7tCTD3JruYE7CwcLv5v1p558AiReKcSqOZLbO5dsHdfDvn
cG8jNB09VOhIJEQa3XMNAaLgEn+RjBj4uli+sMltsVk7
X-Google-Smtp-Source: AHgI3IatX1FJTkaHxqwfBurXKW6DI61kvUbMA8AY6WPg/uiNUQugOZMH/gbXh0hnpBdfnJ09QxROztOefn9G2flbr9c=
X-Received: by 2002:a9d:4687:: with SMTP id z7mr25474495ote.350.1549830209026;
Sun, 10 Feb 2019 12:23:29 -0800 (PST)
In-Reply-To: <83y3b4wdw9.fsf@gnu.org>
X-detected-operating-system: by eggs.gnu.org: Genre and OS details not
recognized.
X-Received-From: 2607:f8b0:4864:20::32f
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:233205
Archived-At:
Am Do., 11. Okt. 2018 um 20:13 Uhr schrieb Eli Zaretskii :
>
> Having written the documentation of the module API, I couldn't help
> but notice a few oddities about its repertory. I list below the
> issues that caused me to raise a brow, for the record:
>
> . Why do we have functions to access vectors, but not functions to
> access lists? I always thought lists were more important for Emacs
> than vectors. If we are asking users to use 'intern' to access
> 'car' and 'cdr', why not 'aref' and 'aset'?
>
> . Why aren't there API functions to _create_ lists and vectors?
I guess these are mostly historical. These were introduced in
https://github.com/aaptel/emacs-dynamic-module/commit/016e8b6ffdfb861806957bb84c419a3d65caedb7,
but I don't remember the background.
>
> . 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.
>
> . 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.
>
> . 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.
>
> 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.
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