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.
Jim Blandy <jimb@xxxxxxxxxx> writes: > 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.) The following one doesn't seem to have anything to do with GC per se. > > 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. And this one has a GC-related problem, but the last paragraph indicates there is also a non-GC-related problem. > > 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. Thomas