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.
[the inherited thread attributions seem confused so I've
just dropped them.]
>>> 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.)
The question is why might EXTRACT_DOUBLE _necessarily_ GC?
As one example, I've been thinking of (eventually) making the NUMBER?
type in Pika extensible in Scheme in order to create an environment
for playing around with continued fraction representations, the
representation that Boehm has written about, and, just to be weird,
Conway's construction of numbers.
Oh, and another example: aren't there some systems in which bignums
are implemented in Scheme (presumably using code that conses)? So if
I have, for example, an exact rational whose numerator and denominator
are both bignums.....
In general, EXTRACT_DOUBLE may wind up GCing if it has to do some
reduction to turn a number into a floating point representation.
Another example, one that applies to _all_ EXTRACT_* functions, is
that of an external store. You may have a reference to a value before
you have the actual value and need to do a database or network
transaction (or whatever) at the time that you actually demand the
objects value.
-t