From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Oddities with dynamic modules Date: Mon, 11 Feb 2019 17:45:52 +0200 Message-ID: <83tvhal45r.fsf@gnu.org> References: <83y3b4wdw9.fsf@gnu.org> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="166387"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org To: Philipp Stephani Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 11 16:46:19 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 1gtDml-000guZ-5I for ged-emacs-devel@m.gmane.org; Mon, 11 Feb 2019 16:46:19 +0100 Original-Received: from localhost ([127.0.0.1]:51938 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gtDmf-0003rX-1L for ged-emacs-devel@m.gmane.org; Mon, 11 Feb 2019 10:46:13 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:33321) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gtDmY-0003rE-M9 for emacs-devel@gnu.org; Mon, 11 Feb 2019 10:46:07 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:33083) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gtDmX-0000Ik-Tt; Mon, 11 Feb 2019 10:46:05 -0500 Original-Received: from [176.228.60.248] (port=3002 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gtDmX-0008NP-Lr; Mon, 11 Feb 2019 10:46:05 -0500 In-reply-to: (message from Philipp Stephani on Sun, 10 Feb 2019 21:23:18 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:233218 Archived-At: > 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. IME, inconvenient interfaces are the main reason for them being unstable, but that's me. > > . 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? > > . 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. > > 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. > 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?