Jim Blandy <xxxxxx@redhat.com> 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