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