Email list hosting service & mailing list manager

(Previous discussion continued)
Re: I don't believe in "(may GC)" Felix Winkelmann (06 Jan 2004 07:55 UTC)

Re: I don't believe in "(may GC)" Felix Winkelmann 06 Jan 2004 07:55 UTC

Am Tue, 06 Jan 2004 08:39:47 +0100 hat Michael Sperber
<xxxxxx@informatik.uni-tuebingen.de> geschrieben:

>>>>>> "Thomas" == Thomas Bushnell <xxxxxx@becket.net> writes:
>
> Thomas> Richard Kelsey <xxxxxx@s48.org> writes:
>
>>>    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.
>
> Let me rephrase: In what kind of environment would "hairy"
> *necessarily* imply "GC-causing"?
>
> (There used to be a version of Scheme 48 where the equivalent of
> SCHEME_EXTRACT_LONG could cause a GC because it could do a callback.
> This was an implementation convenience, not a necessity, and it's gone
> now.)
>

Well, good for you! But what should other implementations do?

(This is also related to the problem SCHEME_RECORD_P has in Gauche)

Face it: the completely arbitrary list of primitives that "may" or "may
not"
GC is a serious problem - you just won't find a solution that fits
all implementations, but there are alternatives that can circumvent
this problem entirely.

Admittedly, this will need a major design change, but, what is the
SRFI draft period there for, if not for weeding out bad designs! ;-)

cheers,
felix