This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 contain all messages, not just those from before July 7th, 2015.
> From: Richard Kelsey <kelsey@xxxxxxx>
> Date: Sun, 4 Jan 2004 17:21:41 -0800 (PST)
> From: Tom Lord <lord@xxxxxxx>
> The draft FFI says:
> double SCHEME_EXTRACT_DOUBLE(scheme_value)
> char * SCHEME_EXTRACT_STRING(scheme_value)
> Neither says "(may GC)".
> If I'm using some exotic number representation (constructive reals,
> perhaps), then EXTRACT_DOUBLE may very well involve some pretty hairy,
> hence possibly GC-causing, computation.
> This doesn't worry me too much; there aren't a lot of such
> implementations around.
How about implementations that implicitly force promises?
> If I'm using some exotic string representations (I'm working on a
> functional-splay-tree string type for Pika) -- same deal:
> extract-string may take some (possibly GC-causing) work.
> This does worry me (it's listed in the 'issues' section of the SRFI).
> I think we went overboard here. Something like
> SCHEME_EXTRACT_STRING_CONTENTS(scheme_value, index, count, buffer)
> which copies 'count' characters starting from 'index' into 'buffer'
> would be better. Presumably this can be done without GCing.
In the case of a splay string, sure. In the case of a lazilly
instantiated string, not so obviously. (Mobile code, perhaps?)
> Even something innocent like:
> int SCHEME_CHAR_P(scheme_value)
> can cause GC if my implementation let's me attach to a hook in its
> implementation.
> Again, I don't think this will be very common. Is there an
> existing implementation for which this (or anything similar) is
> an issue?
That supports hooks in arbitrary Scheme primitives? I presume so.
But you've lost me on why "not common" or "no implementation does that
[quite reasonable thing] yet" arguments are relevent to this FFI.
Regarded as a social engineering hack, I presume that the reason to
make this an FFI is to (a) lead to lots of libraries being given
FFI-using wrappers; (b) lead to lots of implementations supporting
the FFI. Great goals -- but there's no reason to gratuitously
force all present and future implementations to emulate the GC
idiosyncrasies of S48.
-t