Newsgroups: comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!rochester!udel!news.mathworks.com!newsfeed.internetmci.com!in1.uu.net!fi.gs.com!netnews.fi.gs.com!mcmanr
From: mcmanr@nytrdc19.eq.gs.com (Russ McManus)
Subject: Re: STOP ME before I CODE in C again!!!
In-Reply-To: abel@netvision.net.il's message of 02 Apr 1996 13:10:26 GMT
Message-ID: <MCMANR.96Apr3100121@nytrdc19.eq.gs.com>
Sender: news@fi.gs.com (Netnews Administrator)
Nntp-Posting-Host: nytrdc19.eq.gs.com
Organization: International Equities - Goldman, Sachs & Co
References: <HJSTEIN.96Mar28125504@blinky.cpaf.com> <315CC818.167E@td2cad.intel.com>
	<ABEL.96Apr2151026@blinky.netvision.net.il>
Date: Wed, 3 Apr 1996 15:01:21 GMT
Lines: 29


   HJS>    -Discussions of what a good FFI should look like, and how it
   HJS>     could be implemented.

One of the first ideas that comes to mind here is making GC as
painless for the extension programmer as possible.  This has already
been accomplished with a couple of different scheme implementations
thanks to a conservative GC.

Also, the number of interfaces should be small.  Instead of having
different functions for extending the interpreter with primitives of
1, 2, 3, ... arguments, implement all new primitives with a single
function.

   HJS>    -Problems with scheme interpreters calling arbitrary C code (and
   HJS>     hopefully, solutions).

The Guile documentation clearly addresses many of these issues.  In
particular, lots of C libraries don't take kindly to being interrupted
at arbitrary points in their execution.  Perhaps the FFI should specify
a way of ensuring that a particular section of code executes uninterrupted.

   HJS>    -Problems with automatic generation of foreign procedure specs.

This would be nice, but I think we could get by without it if there
was a standard C FFI.  The glue routines for a particular library would
only have to be written once, then they could be redistributed as neccesary.

-russ
