[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: I don't believe in "(may GC)"

This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 contain all messages, not just those from before July 7th, 2015.

Am Tue, 06 Jan 2004 08:39:47 +0100 hat Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx> geschrieben:

"Thomas" == Thomas Bushnell <tb@xxxxxxxxxx> writes:

Thomas> Richard Kelsey <kelsey@xxxxxxx> 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

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! ;-)