[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Couple things...
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.