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

[Tom Lord <lord@xxxxxxx>]

    > 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