Re: Emacs ffi

[Andrea Corallo <acorallo@gnu.org>]

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