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.
On Mon, 5 Jan 2004, Richard Kelsey wrote: > 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. SISC allows inexact reals of greater precision than the hardware can directly represent, and places the precision of inexact computations under user control by allowing the user to set two "special variables" named min-precision and max-precision. Chicken can be compiled with an extended numeric library to support inexact-reals represented as floating point numbers of any chosen size. I dunno their exact internals, but do you really wanna bet that both of them wouldn't have difficulty implementing an EXTRACT_DOUBLE that didn't allocate a call frame? > If I'm using some exotic string representations (I'm working on a > functional-splay-tree string type for Pika) -- same deal: > extract-string may take some (possibly GC-causing) work. > >This does worry me (it's listed in the 'issues' section of the SRFI). > > Even something innocent like: > > int SCHEME_CHAR_P(scheme_value) > > can cause GC if my implementation let's me attach to a hook in its > implementation. > >Again, I don't think this will be very common. Is there an existing >implementation for which this (or anything similar) is an issue? The lack of existing implementations that use an "exotic" representation for strings is one of the main reasons I wound up writing my own. I don't know whether you'd say that my homebrew system "exists" or not since it's not released, but handling long strings and Unicode is the only thing it does *better* than other schemes, and an exotic character and string representation is why it can do it. So this is more than just closing the door on something that nobody's doing; it's closing the door on things that are, for some applications, The Right Thing. In Natural-Language work, it's not that uncommon to *want* a string that's the entire text of a novel when you're doing corpus work, and the natural method of parsing and annotating concentrates on adding and deleting characters usually near the front of the string. That's horribly inefficient with c-style strings. Until I got my tree representation of strings working, I had to deal with novels with much more complicated code, a page at a time or less, so as not to force the underlying implementation to do something terribly inefficient. I don't think it's okay to lock implementors out of using this "exotic" representation, when they may want to go to it as a means of *improving* their schemes or adapting to the new realities of Unicode Support. And this is important to your design because, if I want to traverse a stringtree copying characters into a C buffer, I do have to allocate a linked list of pointers to parent nodes in the string, and that may trigger GC. Bear