From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Corallo Newsgroups: gmane.emacs.devel Subject: Re: Emacs ffi Date: Fri, 16 Aug 2024 16:07:31 -0400 Message-ID: References: <864j7qhup6.fsf@gnu.org> <87a5hi0yts.fsf@valhala.localdomain> <86y152ge0b.fsf@gnu.org> <86jzgjfwqp.fsf@gnu.org> <87sev78arx.fsf@gmail.com> <86le0z89u1.fsf@gnu.org> <87o75v87n1.fsf@gmail.com> <86frr786k7.fsf@gnu.org> <86frr66s0o.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21868"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: suhailsingh247@gmail.com, gerd.moellmann@gmail.com, nicolas@n16f.net, arthur.miller@live.com, emacs-devel@gnu.org, Eli Zaretskii To: Christopher Dimech Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Aug 16 22:08:18 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 1sf3FC-0005Y0-3C for ged-emacs-devel@m.gmane-mx.org; Fri, 16 Aug 2024 22:08:18 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sf3EU-0000K4-Uy; Fri, 16 Aug 2024 16:07:34 -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 1sf3ET-0000Jq-4l for emacs-devel@gnu.org; Fri, 16 Aug 2024 16:07:33 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sf3ER-0006by-Tp; Fri, 16 Aug 2024 16:07:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=PVT+HDAkWa//CSZr//qonW1/MCTPz99ck32+U2w/I+8=; b=WIFL60WQbRfiJW75mkRi ttCJy3KSZyJPBMbSmP/Netc5tgh9bPrcEB8H5wXwVKK55EeYzKPWjtv/1sDP/8qy2aHkqd9JRozBp VK8ivlQ7VjWAl1wtlMM0CoL+8JuqsJILfu+cgYN9s5/qbYk3W/XLlJ5bYSLpQK28qJ8hsGaVU1GZ6 l9XWuV77aG4YEqJEmkPSYt9B2yLluiVISxdReY1zDmlax1plwNYD+Y+ja603Lq89Snk2M+h+U54FZ ofXIRq3YEmaO9WHJdr7W4uVuXjMORJO67v1HlG4TSVbfU2KFH7M8KB6NxJWVJJOOoNUheW3FB14Og TIx2Riym5shVnQ==; Original-Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1sf3ER-0007SN-IG; Fri, 16 Aug 2024 16:07:31 -0400 In-Reply-To: (Christopher Dimech's message of "Thu, 15 Aug 2024 23:02:42 +0200") 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:322814 Archived-At: Christopher Dimech writes: >> Sent: Friday, August 16, 2024 at 8:32 AM >> From: "Andrea Corallo" >> To: "Eli Zaretskii" >> 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 writes: >> >> >> From: Andrea Corallo >> >> Cc: Suhail Singh , 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 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