>From: Richard Kelsey <xxxxxx@s48.org>
Subject: Re: I don't believe in "(may GC)"
Date: Mon, 05 Jan 2004 07:06:44 -0500

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

If the function fills the buffer with the internal character
encoding, yes, it can probably be done without GC.
If the function specifies the buffer to be filled by a specific
encoding (such as utf-8), this may call GC, since the system need to
do conversion, which may allocates memory.

(BTW, The semantics of 'index' and 'count' need to be clearified,
w.r.t. the what-is-a-character issue.)

>    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?

For the primitive types such as chars, numbers and strings, no, AFAIK.
However, SCHEME_RECORD_P could cause GC in Gauche at least in the
current implementaiton.   Though it is pretty nasty situation in the
srfi-50 style record API, so I can avoid it if required.

Gauche has CLOS-style object system, and srfi-9 record type
is implemented as a <record> class.  It can be subclassed by Scheme,
so SCHEME_RECORD_P theoretically needs to check the passed object
is either an instance of <record> or its subclasses.
In order to check that, Gauche takes the class of the passed
object; now, Gauche also allows an instance to change its classes,
(including redefining class), and when the instance's class has
been changed or redefined, the ClassOf() operation invokes instance
update protocol, which allocates memory.

Mainly for performance reasons, Gauche prohibits changing
classes of primitive types.  I'd do that for record types
as well, if I'd ever implement srfi-50 in the current style.

--shiro