Re: I don't believe in "(may GC)"

[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.

   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.

   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?

                                           -Richard Kelsey