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)" Shiro Kawai 05 Jan 2004 12:45 UTC

>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