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