bear <xxxxxx@sonic.net> writes:
> 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.

Wow --- thanks for writing that up.

It looks like all of these are problems stemming from the restrictions
on when GC can happen --- is that right?  (Your original post didn't
specify that that was specifically the issue; it just said the SRFI
would be difficult to implement.)