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