Email list hosting service & mailing list manager

(Previous discussion continued)
Re: no constants please Richard Kelsey (04 Jan 2004 18:09 UTC)
Re: no constants please felix (04 Jan 2004 19:28 UTC)
Re: no constants please Richard Kelsey (04 Jan 2004 20:06 UTC)
Re: no constants please Tom Lord (04 Jan 2004 21:39 UTC)
Re: no constants please Tom Lord (04 Jan 2004 22:09 UTC)
Re: no constants please Richard Kelsey (04 Jan 2004 22:58 UTC)
Re: no constants please Tom Lord (05 Jan 2004 01:16 UTC)
Re: no constants please Tom Lord (05 Jan 2004 01:45 UTC)
Re: no constants please Richard Kelsey (05 Jan 2004 11:40 UTC)
Re: no constants please Tom Lord (05 Jan 2004 16:51 UTC)
Re: no constants please Richard Kelsey (05 Jan 2004 17:48 UTC)
Re: no constants please Tom Lord (05 Jan 2004 18:50 UTC)
Re: no constants please Michael Sperber (05 Jan 2004 18:48 UTC)
Re: no constants please Tom Lord (05 Jan 2004 22:26 UTC)
Re: no constants please Michael Sperber (06 Jan 2004 07:42 UTC)
I don't believe in "(may GC)" Tom Lord (05 Jan 2004 01:21 UTC)
Re: I don't believe in "(may GC)" Richard Kelsey (05 Jan 2004 12:06 UTC)
Re: I don't believe in "(may GC)" Shiro Kawai (05 Jan 2004 12:45 UTC)
Re: I don't believe in "(may GC)" bear (05 Jan 2004 18:16 UTC)
Re: I don't believe in "(may GC)" Tom Lord (05 Jan 2004 17:00 UTC)
Re: I don't believe in "(may GC)" bear (05 Jan 2004 17:53 UTC)
Re: I don't believe in "(may GC)" tb@xxxxxx (06 Jan 2004 01:39 UTC)
Re: I don't believe in "(may GC)" Michael Sperber (06 Jan 2004 07:39 UTC)
Re: no constants please Tom Lord (05 Jan 2004 01:31 UTC)
Re: no constants please Tom Lord (05 Jan 2004 01:38 UTC)
Re: no constants please Richard Kelsey (05 Jan 2004 12:16 UTC)
Re: no constants please Tom Lord (05 Jan 2004 18:05 UTC)
Re: no constants please Michael Sperber (05 Jan 2004 19:03 UTC)
Re: no constants please tb@xxxxxx (06 Jan 2004 01:37 UTC)
Re: no constants please Richard Kelsey (06 Jan 2004 02:14 UTC)
Re: no constants please Tom Lord (06 Jan 2004 02:55 UTC)
Re: no constants please tb@xxxxxx (06 Jan 2004 02:31 UTC)
Re: no constants please Richard Kelsey (06 Jan 2004 03:09 UTC)
Re: no constants please tb@xxxxxx (06 Jan 2004 03:14 UTC)
Re: no constants please Tom Lord (06 Jan 2004 04:32 UTC)

Re: I don't believe in "(may GC)" bear 05 Jan 2004 17:53 UTC


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