From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: Dynamic FFI vs Static FFI (was Re: About Guile crypto support) Date: Tue, 12 Feb 2013 02:40:43 -0500 Message-ID: <87pq06x9ms.fsf_-_@tines.lan> References: <1359896146.2754.19.camel@Renee-desktop.suse> <871ucvof60.fsf@gnu.org> <1360032192.2754.61.camel@Renee-desktop.suse> <87mwvisqwj.fsf@gnu.org> <878v6yojxg.fsf@gnu.org> <87sj55bjxz.fsf@gnu.org> <1360576299.5068.20.camel@Renee-desktop.suse> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1360654869 10164 80.91.229.3 (12 Feb 2013 07:41:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 12 Feb 2013 07:41:09 +0000 (UTC) Cc: Andy Wingo , Ludovic =?utf-8?Q?Court=C3=A8s?= , guile-devel@gnu.org To: Greg Troxel Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Feb 12 08:41:28 2013 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1U5AUX-0007aF-5M for guile-devel@m.gmane.org; Tue, 12 Feb 2013 08:41:25 +0100 Original-Received: from localhost ([::1]:45080 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U5AUD-0005Lu-NG for guile-devel@m.gmane.org; Tue, 12 Feb 2013 02:41:05 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:57295) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U5AUB-0005LU-H5 for guile-devel@gnu.org; Tue, 12 Feb 2013 02:41:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U5AUA-0008Qa-8h for guile-devel@gnu.org; Tue, 12 Feb 2013 02:41:03 -0500 Original-Received: from world.peace.net ([96.39.62.75]:44067) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U5AUA-0008QJ-4V; Tue, 12 Feb 2013 02:41:02 -0500 Original-Received: from 209-6-91-212.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([209.6.91.212] helo=tines.lan) by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1U5AU2-0003Ys-K6; Tue, 12 Feb 2013 02:40:54 -0500 In-Reply-To: (Greg Troxel's message of "Mon, 11 Feb 2013 10:23:14 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 96.39.62.75 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:15733 Archived-At: Greg Troxel writes: > This .so=>devel does not make sense to me. I thought the point was > that -devel split things that people who wanted to compile against the > package needed, but not things needed to run. It seems to me that the dynamic FFI performs, at run time, the same jobs that a C compiler performs at compile time. If at some point we add support for accessing preprocessor macros and type definitions (which seems important), then we'll need the header files as well. So it makes sense to me that a full-featured dynamic FFI fundamentally depends on information that's only available in the *-dev packages. At some point, it might make sense to create a more static FFI that works more like a C compiler does, splitting the job into compile-time and run-time phases. This static FFI would be strictly less powerful than the dynamic FFI, in a similar sense to how syntactic record APIs are less powerful than procedural ones. However, the static FFI would be sufficient in most cases, and would have some advantages. Thoughts? Mark