From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: arthur miller Newsgroups: gmane.emacs.devel Subject: Sv: as for Calc and the math library Date: Tue, 13 Aug 2024 21:43:00 +0000 Message-ID: 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> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_000_DU2PR02MB10109EC49CF2C6716AD19C0EE96862DU2PR02MB10109eu_" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13594"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "nicolas@n16f.net" , "emacs-devel@gnu.org" To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Aug 14 06:27:35 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 1se5bh-0003Is-HV for ged-emacs-devel@m.gmane-mx.org; Wed, 14 Aug 2024 06:27:34 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1se5b1-0003X7-Ro; Wed, 14 Aug 2024 00:26:51 -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 1sdzIk-0002HY-Fm for emacs-devel@gnu.org; Tue, 13 Aug 2024 17:43:34 -0400 Original-Received: from mail-northeuropeazolkn19013012.outbound.protection.outlook.com ([52.103.32.12] helo=DUZPR83CU001.outbound.protection.outlook.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sdzIg-0000z2-Qy; Tue, 13 Aug 2024 17:43:34 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=RFA39rTPfDh81hApK+QMnLxhWD7ez+g2dlMF6m8e5NZwc9IQ2QpfF0SMbaVrNnlGytt3rsJHSGxeFcy8fViLSL6tuokq1xln8hcayttqwiukQKdrwmXN0iZyj0NRboql0Ij3GRy4lyrFf5arCXoWMVMalOADqsoCgvDfpjg5ROZ94Uu0eSrliblpRy/+wVo0Dn9M8FGHAE05XhWvo2Mdad3je3ntJVVy7NXeUe4O6ql/Td7EhGu2QpRsEihVJWWZiqU7u2H16VN9mt8ZqBlqDA8cvD85ku+UxA4y39A2pGuxcESnETKWXyxsjIU/qlHitIlz9B3cUMMtJ+hPsb2XhA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=/2/MgULuZ4HbhqsLaY7hSpixC6mXiXfVaKa3iNz8Dkk=; b=silyFdv3jvwTUzOkjvrmWtOxGXxeX+BQGhsuwWQcA7DABFYI2K24+iLKMDZplzZqQBPPa1DlTIfpsqppZpfpQVW2iiEvG7MvcpA2F6twa+lV/K61CORQ/h4+1kj4cS2plMuR/8fctaR3a506GtjbbGDDFbxa0K9dDdEnY6otHi5dSL1K/B9ETDTll3OyaGmH3BdnidIvElZO7wPqVizWjznJwGRiXHkrC5ExmEBRm+cwfIeoxWICNGkomg4n0NFysWrQbcZYjwZtE1M1RFaX8N9dxlylqpTIezXfvSClTMuE8d2FAXL3ABiKK1FHWjy1ZsCS+zKG8SYPMuY9mw+cGQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=live.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/2/MgULuZ4HbhqsLaY7hSpixC6mXiXfVaKa3iNz8Dkk=; b=mGsQAkmLlVTs4XjMaK45nLjfd1mh8fYX0ikRM9HQFg7M7AapMKa+uVA85lRVVg3wWhJETD9BGpx0grXW0WEpG+c3qt4W++9v5LCei7PeV0bNHf+WFq8lVTyxd3JqSQ/EwCixZQnQJ95YVn0WMc3HOhG1M8aVJaIctHbjB8t9E4uDT/oRdESq8cruyPdMGjTCUaJzLEmM5b2JsE5WkfgInH+tg8MZnMf/FFRnZa4uhOuoGKeE7kGiTAeqZy0V/mdfKEPpD4Y59Ca9eGytmTP0iSgiTBPP6fhn9Kf9TmfyE4I1eny/ih+ecAk8ZV7SH4h+gQXRFctpqKvqQvVVYGkNJA== Original-Received: from DU2PR02MB10109.eurprd02.prod.outlook.com (2603:10a6:10:497::14) by DB8PR02MB5849.eurprd02.prod.outlook.com (2603:10a6:10:f8::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7849.22; Tue, 13 Aug 2024 21:43:00 +0000 Original-Received: from DU2PR02MB10109.eurprd02.prod.outlook.com ([fe80::f3c9:d4cb:290:d487]) by DU2PR02MB10109.eurprd02.prod.outlook.com ([fe80::f3c9:d4cb:290:d487%4]) with mapi id 15.20.7875.016; Tue, 13 Aug 2024 21:43:00 +0000 Thread-Topic: as for Calc and the math library Thread-Index: AQHa7HhyCr4HNzb0tkSg9b4Ke04UmbIjdNFDgAAGX1aAAAZxKoAABt/dgAAT+BqAASgZ9IAAVrozgACZUz0= In-Reply-To: <86bk1whb9v.fsf@gnu.org> Accept-Language: sv-SE, en-US Content-Language: sv-SE x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [DCyRYTpmB3UCT+sO4DgLdXKvhvNmjmy5] x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DU2PR02MB10109:EE_|DB8PR02MB5849:EE_ x-ms-office365-filtering-correlation-id: 29a7173c-b829-4f33-ce2f-08dcbbe0e6ed x-microsoft-antispam: BCL:0; ARA:14566002|9400799024|15030799003|15080799003|461199028|12050799009|19110799003|8060799006|102099032|440099028|4302099013|3412199025|1602099012; x-microsoft-antispam-message-info: gkfPWsJeHkeU+hJej5pm2/xNid3Xeo2/I/Zsxikh9wvNfJELGlfCgYlMCK+za/DnVRSw+p5I4b96E66leGYFcqRj+BHaChEKyVSn2+2iAfgO4IhfdP2R/BFDqon8Y2zEFA2t9voelpD6xALFCu01AXKV9QtQzR2y1H20kkqbhu5zU3TGsurSDYAW2TnOo0hXD0gJc8Jk34TE4xkuomr7vQ9xz1uF2Hs6bnZGt3qTb9flrsZd8d4fBgEmoo0Fu+mii9h6kkqnjn7q9j5OXeuXpwJR/XfU5g/PxGTzONCScpw2OcRgPHWyOmbiQ07qPPRVEZbM/zLY+iZ9lLTPCWn2gLKq2164fg/blnZ2dmnaL+J0t2pY4YTaKfEKXmuyIiKE5P6D1kEP996fa+dm1xGCmEIb8DvVt4dM6yENDWrZNAgCx1L2VIiyoeUKzyPRpbU628z9VoNJmQFmg/MUFV3AObb4cASeP1hCzfk7Gdlmo368iulcXRXjTs1X2YflaE2IyG+ooo2s4HAdhVWA+a/c2zLksf31SZYoGDWFDx3XaBVBnDbfX0JNSrV9S9GqcU8n3omRme31iNGDthiBmztPzvDtwC9P6G2wQlOf8YxlRwSMPOd8BTPgdFw5hRdvtKY5sPyNE5vcTWEmTv37qC7/C3F+daXhfgfLXB8SvANKOvfi/3+zsOznmODSL4Gw93OwsrbhcJfNFoVew6TtRsyWLg0mQxXiJlZ3td1F7DGcDqbr26G4v/ZpsYuQqhwdB Kv6vLI4p5wA7Zci6andrZW+G3ZYvEREqot383EvBlZiTCVcf7llQLSwUIPf9ViLJRETmMAXfVKeIfsZ2ruQksgKODSjy9iNlX6 x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?VI0MPS9THcvLXo1Z206ENYMz6PeJjAIdc1EWoPLfdD3A7vdVK5oOrTiwMb?= =?iso-8859-1?Q?l5ziKA8ElqF/RBxMKCIRD6ljn68taCIv4tLIPjIYXrophKfE2CiAVx6KlY?= =?iso-8859-1?Q?Oo/ZfG5URVDqZPbxc4QXRrelEyNdEWdS7rEiyrdAsVFqf3cjm3G2e015im?= =?iso-8859-1?Q?OtgLxPh9oYjSmMPaGcfVAvzgv4rOuYuPp7EgUT5aiuqnp9Lyg9LxMnCSgQ?= =?iso-8859-1?Q?P5uYWS8BHdsc3EpF1yb5dZEjHUsFTTVDyCZqCFSFf1x41tBIm6fBFSF6EO?= =?iso-8859-1?Q?jMMRJgZaSsxBaTFeHETbFhTDt7Hiz3YCAJNjk2E9O0uHfaAo7qxt+l8Lbn?= =?iso-8859-1?Q?OEK8rMONZD7xKrhIeL23/2LEV9oAG7y6ouu7PQSD518C1F2sGMq3WzB2Bv?= =?iso-8859-1?Q?LQKgZtGTSM9vVWiOggp1w5Uo4EhJRb0RTC/nx+qFNHaj3AOyDaW5ez1trG?= =?iso-8859-1?Q?FN1OpZxkFAAOWRFHDzMKtPoxidZzQWPIEfWamzVoeLIZ8hUmwF8I1UGO9N?= =?iso-8859-1?Q?ZOyOCY6TtUOIlOHMmjQmNsIagJErWPkfFVJT+/jnTarWiH8/a0JTKSS+Gt?= =?iso-8859-1?Q?tyz5aTpRhPQJ0eANqHoB8SowmEmDHrXuKMbYvb7ZdeM1l294Lg7dOyoqtq?= =?iso-8859-1?Q? X-OriginatorOrg: sct-15-20-7828-19-msonline-outlook-12d23.templateTenant X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DU2PR02MB10109.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 29a7173c-b829-4f33-ce2f-08dcbbe0e6ed X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Aug 2024 21:43:00.0994 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR02MB5849 Received-SPF: pass client-ip=52.103.32.12; envelope-from=arthur.miller@live.com; helo=DUZPR83CU001.outbound.protection.outlook.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Wed, 14 Aug 2024 00:26:48 -0400 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:322727 Archived-At: --_000_DU2PR02MB10109EC49CF2C6716AD19C0EE96862DU2PR02MB10109eu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > > > > Eli Zaretskii writes: > > > > > > > > > We made the effort to allow loading dynamic modules precisely for= this > > > > > reason: to allow free libraries to be used, but not non-free ones= . > > > > Emacs users are "linking" Emacs to all kind of proprietary, non-free se= rvices > > these days. You are reading /r/Emacs yourself and seen packages popping= up > > targeting this or that proprietary service almost every day. Shared lib= raries > > are no longer the staple of distributing closed source. The computing > > landscape > > has change a lot since 1980s/1990s. > > > > > > You absolutely can use non-free dynamic modules: enforcing the exis= tence > > > > of a symbol saying "I promise I'm free" does not change anything. O= ne > > > > could also easily add a free dynamic module that calls non-free > > > > libraries. > > > > > > The need to declare that a library is free and have its sources freel= y > > > available does serve as an obstacle for non-free software. And using > > > non-free library with a free module is against the GPL, so it is > > > illegal. We cannot prevent people from lying and doing illegal > > > things, we can only make it harder. > > > > IMO, licenses are to restrict the usage, not arbitrary technical > > limitations. We could similary have a token declaration in FFI interfac= e, 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. > > You are preventing people not familiar with programming who can't writ= e 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 Ema= cs while possibly being a stopper *only* for unexperienced programmers. > > At the same time, the strategy is slowing down > > Emacs development and make it harder for talented people to actually wr= ite > > useful code for Emacs. It is also growing the C core unnecessary. > > I don't share this view of the Emacs development, of course. And with > all due respect, I don't think you are in a good position to judge > that: you are not involved in this deep enough and long enough to have > the perspective and experience to make such judgments. Sure, I certainly am not experienced nor involved in Emacs as long and as much as you or many others here. However, I think everyone understands possible fears of a company, or even just individuals loading proprietary libraries, which free world (GNU) does= not want to endorse and promote such usage. I don't even disagree that it is un= justified. 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 f= or 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 t= he damage. In this case, considering how easy is to work with C libraries in s= ome 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 is a plethora of MIT licensed math libraries, with big API surfac= es, > > well optimized for many architectures which users could bring into Emac= s > > 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 Emac= s core, and I didn't say anything against modules either. I just say FFI woul= d make it easier and faster. > > Anyway, Guile is the "gnu extension language", and there are no > > problems to expose FFI: > > > > https://www.gnu.org/software/guile/manual/html_node/Foreign-Function-In= terface.html > > > > How come there is no decision against loading shared objects in Guile? = There > > was > > even a discussion, on this very mailing list, of Emacs core re-written = in > > Guile > > (which seems to not happen). That would auto-expose Guile FFI, but that= seemed > > to be OK? > > > > Similar for CLisp and GCL, both are GNU projects and expose FFI. > > These questions are not for me to answer. I'm not responsible for > these other projects. I think they are mistaken, but then the Guile > folks never listened to what I had to say on quite a few subjects, so > I'm not surprised. (I know nothing about how Common Lisp is developed > and what are its goals.) Of course you are not responsible for other projects, nobody thinks you are= . My point is that it is not unthinkable for a GNU project to implement FFI. Als= o, we are not directly seeing commercial companies running toward Guile and linki= ng bunch of proprietary binaries into Guile runtime, and Guile is de facto, a popular Scheme implementation. > 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. There are lots of projects with different needs, some are less, others are more self-containe= d. It all depends how the software is used. Lisp(s), Emacs Lisp included, are usu= ally 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 so= ftware, such as mathematical libraries for example. Anyway, thanks for the arguments; I think it is useful to re-think the argu= ments, regardless on which side of the arguments I am. best regards ________________________________ Fr=E5n: Eli Zaretskii Skickat: den 13 augusti 2024 14:12 Till: arthur miller Kopia: nicolas@n16f.net ; emacs-devel@gnu.org =C4mne: Re: as for Calc and the math library > From: arthur miller > CC: "emacs-devel@gnu.org" > Date: Tue, 13 Aug 2024 07:16:35 +0000 > > > > Eli Zaretskii writes: > > > > > > > We made the effort to allow loading dynamic modules precisely for t= his > > > > reason: to allow free libraries to be used, but not non-free ones. > > Emacs users are "linking" Emacs to all kind of proprietary, non-free serv= ices > these days. You are reading /r/Emacs yourself and seen packages popping u= p > targeting this or that proprietary service almost every day. Shared libra= ries > are no longer the staple of distributing closed source. The computing lan= dscape > has change a lot since 1980s/1990s. > > > > You absolutely can use non-free dynamic modules: enforcing the existe= nce > > > of a symbol saying "I promise I'm free" does not change anything. One > > > could also easily add a free dynamic module that calls non-free > > > libraries. > > > > The need to declare that a library is free and have its sources freely > > available does serve as an obstacle for non-free software. And using > > non-free library with a free module is against the GPL, so it is > > illegal. We cannot prevent people from lying and doing illegal > > things, we can only make it harder. > > 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. > 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 mal= icious > company anyway. People not familiar with programming will be unable to use FFI for anything serious anyway. > At the same time, the strategy is slowing down > Emacs development and make it harder for talented people to actually writ= e > useful code for Emacs. It is also growing the C core unnecessary. I don't share this view of the Emacs development, of course. And with all due respect, I don't think you are in a good position to judge that: you are not involved in this deep enough and long enough to have the perspective and experience to make such judgments. > 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. > Anyway, Guile is the "gnu extension language", and there are no > problems to expose FFI: > > https://www.gnu.org/software/guile/manual/html_node/Foreign-Function-Inte= rface.html > > How come there is no decision against loading shared objects in Guile? Th= ere was > even a discussion, on this very mailing list, of Emacs core re-written in= Guile > (which seems to not happen). That would auto-expose Guile FFI, but that s= eemed > to be OK? > > Similar for CLisp and GCL, both are GNU projects and expose FFI. These questions are not for me to answer. I'm not responsible for these other projects. I think they are mistaken, but then the Guile folks never listened to what I had to say on quite a few subjects, so I'm not surprised. (I know nothing about how Common Lisp is developed and what are its goals.) 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. --_000_DU2PR02MB10109EC49CF2C6716AD19C0EE96862DU2PR02MB10109eu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
> > > > Eli Zaretskii <eliz@gnu.org> writes:
> > > >
> > > > > We made the effort to allow loading dynamic module= s precisely for this
> > > > > reason: to allow free libraries to be used, but no= t non-free ones.
> >
> > Emacs users are "linking" Emacs to all kind of propriet= ary, non-free services
> > these days. You are reading /r/Emacs yourself and seen packages p= opping up
> > targeting this or that proprietary service almost every day. Shar= ed libraries
> > are no longer the staple of distributing closed source. The compu= ting
> > landscape
> > has change a lot since 1980s/1990s.
> >
> > > > You absolutely can use non-free dynamic modules: enforc= ing the existence
> > > > of a symbol saying "I promise I'm free" does = not change anything. One
> > > > could also easily add a free dynamic module that calls = non-free
> > > > libraries.
> > >
> > > The need to declare that a library is free and have its sour= ces freely
> > > available does serve as an obstacle for non-free software. &= nbsp;And using
> > > non-free library with a free module is against the GPL, so i= t is
> > > illegal.  We cannot prevent people from lying and doing= illegal
> > > things, we can only make it harder.
> >
> > IMO, licenses are to restrict the usage, not arbitrary technical<= /div>
> > limitations. We could similary have a token declaration in FFI in= terface, 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.

> > 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 Ema= cs
while possibly being a stopper *only* for unexperienced programmers.

> > At the same time, the strategy is slowing down
> > Emacs development and make it harder for talented people to actua= lly write
> > useful code for Emacs. It is also growing the C core unnecessary.=
>
> I don't share this view of the Emacs development, of course.  And= with
> all due respect, I don't think you are in a good position to judge
> that: you are not involved in this deep enough and long enough to have=
> the perspective and experience to make such judgments.

Sure, I certainly am not experienced nor involved in Emacs as long and
as much as you or many others here.

However, I think everyone understands possible fears of a company, or even<= /div>
just individuals loading proprietary libraries, which free world (GNU) does= not
want to endorse and promote such usage. I don't even disagree that it = is unjustified. 

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 Em= acs for
 whichever purpose, gives a positive incentive for people to see quali= ties in Emacs
 in particular, and implicitly in GNU project.

As with every important decision, there is a balance between the gain and t= he
damage. In this case, considering how easy is to work with C libraries in s= ome
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 is a plethora of MIT licensed math libraries, with big API = surfaces,
> > well optimized for many architectures which users could bring int= o Emacs
> >  themselves.
>
> AFAIU, there should be no reasons not to be able to load MIT licensed<= /div>
> libraries via the emacs-module machinery.

Nobody is stopping anyone to implement anything as modules, outside of Emac= s
core, and I didn't say anything against modules either. I just say FFI woul= d
make it easier and faster.

> > Anyway, Guile is the "gnu extension language", and ther= e are no
> > problems to expose FFI:
> >
> > https://www.gnu.org/software/guile/manual/html_node/Foreign-Funct= ion-Interface.html
> >
> > How come there is no decision against loading shared objects in G= uile? There
> > was
> > even a discussion, on this very mailing list, of Emacs core re-wr= itten in
> > Guile
> > (which seems to not happen). That would auto-expose Guile FFI, bu= t that seemed
> > to be OK?
> >
> > Similar for CLisp and GCL, both are GNU projects and expose FFI.<= /div>
>
> These questions are not for me to answer.  I'm not responsible fo= r
> these other projects.  I think they are mistaken, but then the Gu= ile
> folks never listened to what I had to say on quite a few subjects, so<= /div>
> I'm not surprised.  (I know nothing about how Common Lisp is deve= loped
> and what are its goals.)

Of course you are not responsible for other projects, nobody thinks you are= . My
point is that it is not unthinkable for a GNU project to implement FFI. Als= o, we
are not directly seeing commercial companies running toward Guile and linki= ng
bunch of proprietary binaries into Guile runtime, and Guile is de facto, a<= /div>
popular Scheme implementation.

> For the record: there are other GNU projects that use the same
> "restrictions" on plugins: Gawk, GNU Make, and GCC, to menti= on 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. There are lots of
projects with different needs, some are less, others are more self-containe= d. It
all depends how the software is used. Lisp(s), Emacs Lisp included, are usu= ally
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 so= ftware, 
such as mathematical libraries for example. 

Anyway, thanks for the arguments; I think it is useful to re-think the argu= ments,
regardless on which side of the arguments I am.

best regards
Fr=E5n: Eli Zaretskii <e= liz@gnu.org>
Skickat: den 13 augusti 2024 14:12
Till: arthur miller <arthur.miller@live.com>
Kopia: nicolas@n16f.net <nicolas@n16f.net>; emacs-devel@gnu.or= g <emacs-devel@gnu.org>
=C4mne: Re: as for Calc and the math library
 
> From: arthur miller <arthur.miller@live.co= m>
> CC: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> Date: Tue, 13 Aug 2024 07:16:35 +0000
>
> > > Eli Zaretskii <eliz@gnu.org> writes:
> > >
> > > > We made the effort to allow loading dynamic modules pre= cisely for this
> > > > reason: to allow free libraries to be used, but not non= -free ones.
>
> Emacs users are "linking" Emacs to all kind of proprietary, = non-free services
> these days. You are reading /r/Emacs yourself and seen packages poppin= g up
> targeting this or that proprietary service almost every day. Shared li= braries
> are no longer the staple of distributing closed source. The computing = landscape
> has change a lot since 1980s/1990s.
>
> > > You absolutely can use non-free dynamic modules: enforcing t= he existence
> > > of a symbol saying "I promise I'm free" does not c= hange anything. One
> > > could also easily add a free dynamic module that calls non-f= ree
> > > libraries.
> >
> > The need to declare that a library is free and have its sources f= reely
> > available does serve as an obstacle for non-free software.  = And using
> > non-free library with a free module is against the GPL, so it is<= br> > > illegal.  We cannot prevent people from lying and doing ille= gal
> > things, we can only make it harder.
>
> IMO, licenses are to restrict the usage, not arbitrary technical
> limitations. We could similary have a token declaration in FFI interfa= ce, 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.

> 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.

> At the same time, the strategy is slowing down
> Emacs development and make it harder for talented people to actually w= rite
> useful code for Emacs. It is also growing the C core unnecessary.

I don't share this view of the Emacs development, of course.  And with=
all due respect, I don't think you are in a good position to judge
that: you are not involved in this deep enough and long enough to have
the perspective and experience to make such judgments.

> There is a plethora of MIT licensed math libraries, with big API surfa= ces,
> well optimized for many architectures which users could bring into Ema= cs
>  themselves.

AFAIU, there should be no reasons not to be able to load MIT licensed
libraries via the emacs-module machinery.

> Anyway, Guile is the "gnu extension language", and there are= no
> problems to expose FFI:
>
> https://www.gnu.org/software/guile/manual/html_node/Foreign-Function-Interf= ace.html
>
> How come there is no decision against loading shared objects in Guile?= There was
> even a discussion, on this very mailing list, of Emacs core re-written= in Guile
> (which seems to not happen). That would auto-expose Guile FFI, but tha= t seemed
> to be OK?
>
> Similar for CLisp and GCL, both are GNU projects and expose FFI.

These questions are not for me to answer.  I'm not responsible for
these other projects.  I think they are mistaken, but then the Guile folks never listened to what I had to say on quite a few subjects, so
I'm not surprised.  (I know nothing about how Common Lisp is developed=
and what are its goals.)

For the record: there are other GNU projects that use the same
"restrictions" on plugins: Gawk, GNU Make, and GCC, to mention th= ose I
know about.  So it isn't like Emacs is alone in this.
--_000_DU2PR02MB10109EC49CF2C6716AD19C0EE96862DU2PR02MB10109eu_--