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
<> geschrieben:

>>>>>> "Thomas" == Thomas Bushnell <> writes:
> Thomas> Richard Kelsey <> 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
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! ;-)