From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: as for Calc and the math library Date: Wed, 14 Aug 2024 08:09:53 +0300 Message-ID: <86ttfng066.fsf@gnu.org> References: <864j7qhup6.fsf@gnu.org> <87a5hi0yts.fsf@valhala.localdomain> <86y152ge0b.fsf@gnu.org> <875xs60wmc.fsf@valhala.localdomain> <86wmklho4m.fsf@gnu.org> <86bk1whb9v.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9933"; mail-complaints-to="usenet@ciao.gmane.io" Cc: nicolas@n16f.net, emacs-devel@gnu.org To: arthur miller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Aug 14 07:10:40 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1se6HP-0002PQ-T5 for ged-emacs-devel@m.gmane-mx.org; Wed, 14 Aug 2024 07:10:40 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1se6Gr-00042p-3f; Wed, 14 Aug 2024 01:10:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1se6Go-00042L-Sv for emacs-devel@gnu.org; Wed, 14 Aug 2024 01:10:02 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1se6Gi-000721-32; Wed, 14 Aug 2024 01:10:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=xkfJeDBw6+FDSI0N3kUbfV74xXGYqYF5jnr+m2x1IkU=; b=HHzy02/u3xZ5 Af3jMsF1jDOQzNYR9KPUznyiyY/+EaUigW5MA2/Kj4iyRY0Rw6B0ZzRYbRarmXZmA29paKsCm6VHm ut91qxfzOKmABpcJkR9cY9MImnU2DO67S/RM1LdbxtTsRCcUE8KAMiIswPN8tx0Mc1/1KiuKFm14U vrRgCBd9Iuhh171at1BxXx/VTTJVLfaMqRuNWe9vbtgbpPnq0AKKYS8ZbKJKAaoZqs7k+jfzPXNcW 00EQxLLohcywdYdKDTamA0C46ptbyexFfHuTEKhLQhmNByR/9bCDKEv1GOekP60gk9kjfoBUNj30w swlSqqN9J/985ZpP/3+fsg==; In-Reply-To: (message from arthur miller on Tue, 13 Aug 2024 21:43:00 +0000) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:322728 Archived-At: > From: arthur miller > CC: "nicolas@n16f.net" , "emacs-devel@gnu.org" > > Date: Tue, 13 Aug 2024 21:43:00 +0000 > > > > IMO, licenses are to restrict the usage, not arbitrary technical > > > limitations. We could similary have a token declaration in FFI interface, when > > > loading a library, no? > > > > You are basically reiterating what Nicolas already said, and I > > answered that. I see no reason to repeat my answers to these > > arguments, they are still the same. > > Just justifiying the statement that Emacs could have something similar as > GPL_COMPATIBLE token in Lisp API, just as there is in module API. I don't > think I have seen anyone suggesting that before, at least not what I know of. Then I don't understand what you are suggesting here. What do you mean by "token in Lisp API"? And if you mean something like what we have in the emacs-module machinery, then how is that different from what we already have? > > > You are preventing people not familiar with programming who can't write a > > > simple C wrapper to load a proprietary library, but it ain't stop any > > > malicious > > > company anyway. > > > > People not familiar with programming will be unable to use FFI for > > anything serious anyway. > > I think you have misunderstand what I am saying: my point was that this > situation is making it more tedious for experienced people to work with Emacs > while possibly being a stopper *only* for unexperienced programmers. I understood what you were saying, and I disagree with your assertion that using emacs-module API makes the job harder. If anything, it makes it somewhat easier: it gives the module a way to call Emacs primitives and provides various auxiliary facilities, without which adjusting a library to Emacs would be a very hard job, because Emacs has its own object system that is quite different from that of any programming language that can be used to code a module. I suggest to re-read the "Writing Dynamically-Loaded Modules" appendix to the ELisp manual and imagine how hard it would be to use FFI without many of those facilities provided specifically for dynamic modules. > However, pragmatically, I don't think putting an obstacle is the best way. On the > contrary, I think, making it as easy as possible to use and extend Emacs for > whichever purpose, gives a positive incentive for people to see qualities in Emacs > in particular, and implicitly in GNU project. > > As with every important decision, there is a balance between the gain and the > damage. In this case, considering how easy is to work with C libraries in some > other Lisp implementations, and how faster it would be to write extensions and > experiment with Emacs, the gain is perhaps bigger than the possible loss. There are examples out there what happens when projects take the route you suggest. I cannot say I'm encouraged with LLVM being used for proprietary closed-code extensions and targets, nor am I overwhelmed with the popularity of Guile, which does have unrestricted FFI. So I see no reason to believe what you suggest will bring such significant advantages to Emacs that we should seriously consider lifting the GPL-compatibility restriction. > > > There is a plethora of MIT licensed math libraries, with big API surfaces, > > > well optimized for many architectures which users could bring into Emacs > > > themselves. > > > > AFAIU, there should be no reasons not to be able to load MIT licensed > > libraries via the emacs-module machinery. > > Nobody is stopping anyone to implement anything as modules, outside of Emacs > core, and I didn't say anything against modules either. I just say FFI would > make it easier and faster. See above: I think you are mistaken in your assessment. I don't see any reasons why using FFI would be so much easier than using the existing modules API. Given some simple boilerplate (like the DEFUN macro you can see in test/src/emacs-module-resources/mod-test.c, and other utility functions there), the job becomes quite simple. By contrast, using FFI the programmer would need to figure all this out on their own, and that requires very good familiarity with Emacs internals. > > For the record: there are other GNU projects that use the same > > "restrictions" on plugins: Gawk, GNU Make, and GCC, to mention those I > > know about. So it isn't like Emacs is alone in this. > > I am not sure if it is relevant with non-lisp projects. How so? GNU Make has its own scripting language, and Gawk implements the Awk programming language, which is a full-fledged specialized language for data processing. How is this "not relevant" to our case? Gawk even comes with a small set of extensions written using the plug-in protocol, and I invite you to review them to see how useful they are, even though they are relatively small and do simple tasks. > There are lots of > projects with different needs, some are less, others are more self-contained. It > all depends how the software is used. Lisp(s), Emacs Lisp included, are usually > in somewhat special situation of being relatively isolated islands when it comes > to available software. Common Lisp perhaps being a biggest exception there. > An easy to use FFI makes it easier to take advantage of already existing software, > such as mathematical libraries for example. I think you greatly underestimate the complexity of using FFI-style API to allow Emacs to use a mathematical library. For starters, floating-point values have a very specific representation in Emacs, so you cannot just take a value from the library and use it. Next, most such libraries allocate memory for its data structures (matrices etc.), so using them will need to provide GC glue for freeing the resources when an instance of a data structure is no longer needed. And that is just the tip of a very large iceberg. > Anyway, thanks for the arguments; I think it is useful to re-think the arguments, > regardless on which side of the arguments I am. As a practical example, I suggest to take a library and integrate it with Emacs using the modules API, if you haven't done that already. It is sometimes amazing how many little details need to be figured out and coded for that, when the target is Emacs Lisp.