Re: as for Calc and the math library

[Eli Zaretskii <eliz@gnu.org>]

> From: arthur miller <arthur.miller@live.com>
> CC: "nicolas@n16f.net" <nicolas@n16f.net>, "emacs-devel@gnu.org"
> 	<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.