Email list hosting service & mailing list manager

(Previous discussion continued)
Re: no constants please Richard Kelsey (04 Jan 2004 18:09 UTC)
Re: no constants please felix (04 Jan 2004 19:28 UTC)
Re: no constants please Richard Kelsey (04 Jan 2004 20:06 UTC)
Re: no constants please Tom Lord (04 Jan 2004 21:39 UTC)
Re: no constants please Tom Lord (04 Jan 2004 22:09 UTC)
Re: no constants please Richard Kelsey (04 Jan 2004 22:58 UTC)
Re: no constants please Tom Lord (05 Jan 2004 01:16 UTC)
Re: no constants please Tom Lord (05 Jan 2004 01:45 UTC)
Re: no constants please Richard Kelsey (05 Jan 2004 11:40 UTC)
Re: no constants please Tom Lord (05 Jan 2004 16:51 UTC)
Re: no constants please Richard Kelsey (05 Jan 2004 17:48 UTC)
Re: no constants please Tom Lord (05 Jan 2004 18:50 UTC)
Re: no constants please Michael Sperber (05 Jan 2004 18:48 UTC)
Re: no constants please Tom Lord (05 Jan 2004 22:26 UTC)
Re: no constants please Michael Sperber (06 Jan 2004 07:42 UTC)
I don't believe in "(may GC)" Tom Lord (05 Jan 2004 01:21 UTC)
Re: I don't believe in "(may GC)" Richard Kelsey (05 Jan 2004 12:06 UTC)
Re: I don't believe in "(may GC)" Shiro Kawai (05 Jan 2004 12:45 UTC)
Re: I don't believe in "(may GC)" bear (05 Jan 2004 18:16 UTC)
Re: I don't believe in "(may GC)" Tom Lord (05 Jan 2004 17:00 UTC)
Re: I don't believe in "(may GC)" bear (05 Jan 2004 17:53 UTC)
Re: I don't believe in "(may GC)" tb@xxxxxx (06 Jan 2004 01:39 UTC)
Re: I don't believe in "(may GC)" Michael Sperber (06 Jan 2004 07:39 UTC)
Re: no constants please Tom Lord (05 Jan 2004 01:31 UTC)
Re: no constants please Tom Lord (05 Jan 2004 01:38 UTC)
Re: no constants please Richard Kelsey (05 Jan 2004 12:16 UTC)
Re: no constants please Tom Lord (05 Jan 2004 18:05 UTC)
Re: no constants please Michael Sperber (05 Jan 2004 19:03 UTC)
Re: no constants please tb@xxxxxx (06 Jan 2004 01:37 UTC)
Re: no constants please Richard Kelsey (06 Jan 2004 02:14 UTC)
Re: no constants please Tom Lord (06 Jan 2004 02:55 UTC)
Re: no constants please tb@xxxxxx (06 Jan 2004 02:31 UTC)
Re: no constants please Richard Kelsey (06 Jan 2004 03:09 UTC)
Re: no constants please tb@xxxxxx (06 Jan 2004 03:14 UTC)
Re: no constants please Tom Lord (06 Jan 2004 04:32 UTC)

Re: I don't believe in "(may GC)" Tom Lord 05 Jan 2004 17:00 UTC

    > From: Richard Kelsey <xxxxxx@s48.org>

    >    Date: Sun, 4 Jan 2004 17:21:41 -0800 (PST)
    >    From: Tom Lord <xxxxxx@emf.net>

    >    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