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