[Snow-users-list] accommodating native SRFI implementations

Julian Graham joolean at gmail.com
Sat Sep 29 17:59:15 EDT 2007


Hi Schemers,

  I've been thinking about the best way to port some SRFIs to Snow,
and I'm getting stuck on a few things that I'm hoping you might be
able to help me with.  It seems to me that SRFIs occupy kind of a
unique position among the packages that should be provided by Snow,
because a lot of them have some degree of support compiled into the
interpreters themselves.  Specifically, I've found that support for a
given SRFI in a given interpreter falls into one of three categories:

1. The interpreter includes explicit support for the SRFI, either in
some kind of compiled form or as part of a library of Scheme code
distributed with the interpreter.

2. The interpreter doesn't include explicit support for the SRFI, but
includes sufficient infrastructure such that the reference
implementation for that SRFI can be used directly or one can be
written (for cases in which there is no reference implementation).

3. The interpreter neither supports the SRFI directly nor does it
provide the necessary infrastructure for an external implementation.

  An example of an SRFI with varying levels of native support is
Marc's SRFI-18, "Multithreading support."  Bigloo, for example, has
built-in support for SRFI-18 (case #1); GNU Guile doesn't have
built-in support, but its set of built-in thread functions are
probably sufficient (with a patch or two) to implement SRFI-18 on top
of them (case #2); SCM probably can't do SRFI-18 without some
significant changes to the interpreter's code base (case #3).

  Given such a heterogeneous playing field:

* When the interpreter provides an SRFI implementation (especially an
implementation that's probably done natively for performance reasons),
should a Snow package override this implementation with, say, the
reference implementation from the SRFI draft, which might be less...
performant?  Or should including a snowball for that SRFI be a no-op
for that interpreter platform?

* What should the behavior be when including an SRFI that can't be
implemented on all the platforms Snow supports?  (Should such SRFIs
use the "require" component of the Snow package structure and give a
list of supported Snow hosts?  Or signal an error when a
non-conforming interpreter tries to use the API?)


Thanks,
Julian


More information about the Snow-users-list mailing list