(Previous discussion continued)
|
||
Re: Couple things... Jim Blandy (08 Jan 2004 19:51 UTC)
|
Re: Couple things... Jim Blandy 08 Jan 2004 19:51 UTC
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.)