[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: when GC is permitted

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.

Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx> writes:

> Matthew> It's my understanding that any existing final SRFI _could_ be
> Matthew> implemented by every Scheme implementation with primarily minor
> Matthew> changes -- most can even be implemented entirely in Scheme.  
> That's understanding is mistaken.  A short look reveals at least:
> SRFI 0
> SRFI 4
> SRFI 6
> SRFI 10
> SRFI 14
> SRFI 17
> SRFI 18
> SRFI 21
> SRFI 22
> SRFI 30
> to have the same property.  A more strict interpretation would yield
> more.

Maybe I'm mistaken, but what would prevent an arbitrary Scheme
implementation from trying to implement any of those?  Some of those
require some hackery done to the lexer or other mechanism, but several
of them have near-complete sample implementations entirely in Scheme.
My point wasn't that given any present SRFI I could copy-and-paste a
sample implementation into my R5RS environment and have it
implemented, but that there would be nothing stopping an
implementation author from extending his implementation to support an
SRFI, however, SRFI-50 would only be possibly implemented in Scheme
implementations that already use an FFI similar to this one.

For example, reasons have already been pointed out why the SRFI
couldn't be implemented on top of Pika.

The requirement on which routines may GC would prohibit me from
writing an FFI to interface C code to a Java-based implementation like