From: Mark H Weaver <mhw@netris.org>
To: Greg Troxel <gdt@ir.bbn.com>
Cc: "Andy Wingo" <wingo@pobox.com>, "Ludovic Courtès" <ludo@gnu.org>,
guile-devel@gnu.org
Subject: Dynamic FFI vs Static FFI (was Re: About Guile crypto support)
Date: Tue, 12 Feb 2013 02:40:43 -0500 [thread overview]
Message-ID: <87pq06x9ms.fsf_-_@tines.lan> (raw)
In-Reply-To: <rmid2w6ub6l.fsf@fnord.ir.bbn.com> (Greg Troxel's message of "Mon, 11 Feb 2013 10:23:14 -0500")
Greg Troxel <gdt@ir.bbn.com> 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
next prev parent reply other threads:[~2013-02-12 7:40 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-03 12:55 About Guile crypto support Nala Ginrut
2013-02-03 15:37 ` Thien-Thi Nguyen
2013-02-04 1:14 ` Daniel Hartwig
2013-02-04 3:12 ` Nala Ginrut
2013-02-04 3:35 ` Daniel Hartwig
2013-02-04 4:15 ` Nala Ginrut
2013-02-04 23:03 ` Ludovic Courtès
2013-02-05 2:43 ` Nala Ginrut
2013-02-05 2:57 ` Noah Lavine
2013-02-06 13:58 ` Nala Ginrut
2013-02-05 15:48 ` Ludovic Courtès
2013-02-06 4:18 ` Daniel Hartwig
2013-02-06 4:28 ` Daniel Hartwig
2013-02-08 16:21 ` Ludovic Courtès
2013-02-09 1:37 ` Daniel Hartwig
2013-02-09 15:12 ` Ludovic Courtès
2013-02-09 17:02 ` Andy Wingo
2013-02-09 17:50 ` Mark H Weaver
2013-02-09 20:44 ` Noah Lavine
2013-02-09 21:53 ` Ludovic Courtès
2013-02-11 8:20 ` Andy Wingo
2013-02-11 9:15 ` Thien-Thi Nguyen
2013-02-11 10:46 ` Mike Gran
2013-02-11 13:14 ` Ludovic Courtès
2013-02-11 9:51 ` Nala Ginrut
2013-02-11 15:23 ` Greg Troxel
2013-02-12 1:12 ` Daniel Hartwig
2013-02-12 4:20 ` Nala Ginrut
2013-02-12 5:21 ` Daniel Hartwig
2013-02-12 7:40 ` Mark H Weaver [this message]
2013-02-12 13:52 ` Dynamic FFI vs Static FFI (was Re: About Guile crypto support) Ludovic Courtès
2013-02-12 18:24 ` Mark H Weaver
2013-02-12 21:49 ` Ludovic Courtès
2013-02-14 7:21 ` William ML Leslie
2013-02-15 13:34 ` Nala Ginrut
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87pq06x9ms.fsf_-_@tines.lan \
--to=mhw@netris.org \
--cc=gdt@ir.bbn.com \
--cc=guile-devel@gnu.org \
--cc=ludo@gnu.org \
--cc=wingo@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).