This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 contain all messages, not just those from before July 7th, 2015.
bear <bear@xxxxxxxxx> writes: > On Thu, 8 Jan 2004, Jim Blandy wrote: > > > > >bear <bear@xxxxxxxxx> 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.)