Re: Emacs ffi

[Andrea Corallo <acorallo@gnu.org>]

Christopher Dimech <dimech@gmx.com> writes:

>> Sent: Saturday, August 17, 2024 at 8:07 AM
>> From: "Andrea Corallo" <acorallo@gnu.org>
>> To: "Christopher Dimech" <dimech@gmx.com>
>> Cc: suhailsingh247@gmail.com, gerd.moellmann@gmail.com, nicolas@n16f.net, arthur.miller@live.com, emacs-devel@gnu.org, "Eli Zaretskii" <eliz@gnu.org>
>> Subject: Re: Emacs ffi
>>
>> Christopher Dimech <dimech@gmx.com> writes:
>> 
>> >> Sent: Friday, August 16, 2024 at 8:32 AM
>> >> From: "Andrea Corallo" <acorallo@gnu.org>
>> >> To: "Eli Zaretskii" <eliz@gnu.org>
>> >> Cc: suhailsingh247@gmail.com, gerd.moellmann@gmail.com, nicolas@n16f.net, arthur.miller@live.com, emacs-devel@gnu.org
>> >> Subject: Re: Emacs ffi
>> >>
>> >> Eli Zaretskii <eliz@gnu.org> writes:
>> >>
>> >> >> From: Andrea Corallo <acorallo@gnu.org>
>> >> >> Cc: Suhail Singh <suhailsingh247@gmail.com>,  gerd.moellmann@gmail.com,
>> >> >>   nicolas@n16f.net,  arthur.miller@live.com,  emacs-devel@gnu.org
>> >> >> Date: Thu, 15 Aug 2024 05:31:49 -0400
>> >> >>
>> >> >> Eli Zaretskii <eliz@gnu.org> writes:
>> >> >>
>> >> >> > The way we do it when loading modules requires the _loaded_ library to
>> >> >> > declare itself compatible, by exporting a symbol of a certain name.
>> >> >> > That is an action by the library we load, not by the Lisp program
>> >> >> > which loads it.
>> >> >>
>> >> >> But we could do the same for our hypothetical ffi machinery, that is:
>> >> >> `define-ffi-library' could fail if the shared library is not exporting
>> >> >> the predetermined symbol we expect no?
>> >> >
>> >> > Of course.  But how many such libraries do that?
>> >>
>> >> Dunno, ATM very few if not zero I guess.
>> >
>> > If there are no existing libraries that export the required symbol, it
>> > raises legitimate concerns about the feasibility and utility of the
>> > approach. Essentially, if the mechanism put in place is not supported by
>> > any available libraries, then the mechanism is ineffective and overly
>> > idealistic.
>> >
>> > There exists a large disconnect between theoretical compliance and
>> > practical usability. If the requirements for compliance are so stringent
>> > or specific that no existing libraries can meet them, then it could be
>> > argued that the approach is not grounded in the reality of software
>> > development.
>> 
>> I disagree, this is normal evolution for software ex: every time a new
>> programming language is created (or a new feature is added to it)
>> compilers implement the related support, even if no programs are using
>> that language or that new extension at present.  Is this a large
>> disconnect between theoretical compliance and practical usability?  No,
>> is just that users will come later.
>> 
>> If Emacs requires the symbol maybe compatible libraries will just export
>> it afterwards (given the cost is close to zero). - Andrea
>
> It is imposing an additional requirement that isn't typically necessary 
> in most other environments.
>
> Typically, mathematical libraries are designed to be widely applicable
> and used across various platforms and applications. Requiring these
> libraries to export a specific symbol or be designed with editor
> compatibility in mind is an unnecessary hurdle. Developers of libraries
> do not prioritize compatibility with editors like Emacs.
>
> To overcome the hurdle that Emacs is bringing upon itself, of requiring
> GPL compliance for mathematical libraries, it should provide its own
> built-in library as suggested by E. Berg. It is the pragmatic way to do
> it.  I disagreed with Berg initially, but I can now understand his
> frustrations with the whole emacs design.
>
> Some free software simply cannot be used with GPL-licensed software like 
> Emacs without violating the terms of one or both licenses.  Requiring GPL 
> compliance for integration is banal.  Particularly when Emacs is not the 
> one providing the library.  It will be the user who will be using.  One 
> simply cannot accuse a user to breaking any license if the library is not
> GPL compliant.  The landscape of free software licenses is diverse, with 
> many different licenses with many not compatible with each other. You’d 
> have to put every teenager in the world in jail, and you can’t do that ! 
>
> But this message does not resonate within the minds of the core emacs maintainers, 
> with the trend continuing for many years to come.  Some believe that everybody 
> in the world doesn’t get it about free software, and even that everybody in the 
> world is a crook and that everybody in the world is trying to steal free software 
> and make bad use of it.  I do not approve of such ideas.  Many think they know
> everything about copyright infringement, but never been thrown out of court on 
> a motion to dismiss.  
>
> It's always the same, you'll get prima donna maintainers who are at the same 
> level of priests, who preach a lot about licensing scenarios.  But have never 
> been there, never done it, but preaching a lot about what others can do and what 
> they cannot do.  Too much coercion was surely not what we wanted to apply.

Looking at your Emacs contribution track I guess we have "been there"
and "did it" more than you, so I'm sorry but I don't understand where
*your* preaching is coming from.

This is my last (of very few) replies to you on this subject 👋