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 SISC. -jivera