> > > > Eli Zaretskii <eliz@gnu.org> writes:

> > > >

> > > > > We made the effort to allow loading dynamic modules precisely for this

> >

> > landscape

> > > > libraries.

> > > illegal. We cannot prevent people from lying and doing illegal

> You are basically reiterating what Nicolas already said, and I

> answered that. I see no reason to repeat my answers to these

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

> > company anyway.

> People not familiar with programming will be unable to use FFI for

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.

> > At the same time, the strategy is slowing down

> > Emacs development and make it harder for talented people to actually 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

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

> > problems to expose FFI:

> >

> > https://www.gnu.org/software/guile/manual/html_node/Foreign-Function-Interface.html

> >

> > How come there is no decision against loading shared objects in Guile? There

> > even a discussion, on this very mailing list, of Emacs core re-written in

> > (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. Also, we

are not directly seeing commercial companies running toward Guile and linking

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

Anyway, thanks for the arguments; I think it is useful to re-think the arguments,

regardless on which side of the arguments I am.

best regards