On Thu, 8 Jan 2004, Jim Blandy wrote:

>
>bear <xxxxxx@sonic.net> writes:
>> For the last little while, I've been looking at this SRFI and
>> realizing that it would be an *AMAZING* amount of work to provide it
>> in the context of my particular scheme implementation.
>
>More work than to provide it in, say, Scheme 48 or MzScheme?  Can you
>sketch why?

I don't really know MzScheme or S48 internals, but my particular
issues are:

1. Lack of agreement with C conventions over what a character is.
   My characters are multi-codepoint sequences and C treats
   single codepoints as characters.  This makes indexes and counts
   in strings wonky.

2. Non-contiguous string representation which is impossible to
   collect the characters from without using memory.  I can set aside
   memory for doing this in advance so as to be able to (probably)
   do it without allocation (which carries the risk of GC) but it
   would be a major pain in the tush. SCHEME_EXTRACT_STRING would
   have to return a pointer at a specially-allocated area with a
   write-through barrier that hooked a routine to propagate changes
   through to the real scheme string in a different representation,
   which would be a horrible efficiency hit.

3. Non-primitive numeric representations.  It's trivial to
   extract a double (or other primitive representation) from most
   of them, but annoying to do without allocating call frames and
   possibly invoking GC. It's do-able, and not nearly as much of
   a pain as strings, but it's there.

4. My runtime does not have a C stack, at all, and allocates all
   call frames on the heap, with attendant risk of garbage
   collection.  To the extent that there are primitive-data stacks,
   they're small structures allocated inside the scheme call-frames,
   on the heap.  (note that this is also part of the source of pain
   for items 2 and 3 because it means I can't funcall or call to C
   without allocating on the heap.  The only way to forestall GC is
   to preallocate before getting into the area GC is locked out of).

   I've used C as a misspelled assembly language, with control flow in
   terms of primitive data on stacks inside the scheme call frames and
   goto instructions, rather than in terms of procedure calls.  Basically
   there's just enough "stack space" in a given frame to call whatever C
   library functions the routine whose frame it is needs.

   This makes the identified semantics for signalling errors (and
   unwinding the stack) difficult to interpret.

				Bear