On Thu, 8 Jan 2004, Jim Blandy wrote:
>bear <firstname.lastname@example.org> 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
I don't really know MzScheme or S48 internals, but my particular
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.