[r6rs-discuss] comment and vote (if allowed)

Aubrey Jaffer agj at alum.mit.edu
Fri Aug 24 22:08:37 EDT 2007

 | Date: Fri, 24 Aug 2007 06:05:03 -0700 (PDT)
 | From: Elf <elf at ephemeral.net>
 | On Tue, 21 Aug 2007, Thomas Lord wrote:
 | <snip>
 | > Those of us who aren't entirely excited about 5.97 have solid
 | > criticisms all around, in my view, but we now "owe the
 | > community" (so to speak) some work to back up our criticisms
 | > with a  pragmatic alternative.
 | fair enough.  pragmatic alternative to r5.97, based on the 'guiding
 | principles' section of the 1 mar 2006 r6rs status report:
 | * allow programmers to create and distribute substantial programs and
 |    libraries eg SRFI implementations, that run without modification in
 |    a variety of Scheme implementations;
 | clearly, we need some form of module/library system and some means of
 | publishing what modules are available.  we already have SRFIs 0, 7,
 | and 55; additionally, most implementations have some form of module
 | system.  what would be the functionality intersection of the SRFIs and
 | assorted module systems?

Take a look at SLIB (http://swiss.csail.mit.edu/~jaffer/SLIB).  It has
a library system supporting many SRFIs and other useful modules on
nearly every R4RS/R5RS implementation.

 | furthermore, in the interests of interoperability, would it be
 | possible for each implementation to publish its differences from
 | the standard as a module (or library) that could be included with a
 | module system (ie, if i am running chicken, an ideal module system
 | would allow me to add a 'guile' module for whatever functionality
 | guile has outside of r6rs, etc)?  this may require some meta-FFI
 | semantics for expressing scheme to outside languages.  there are
 | also some clear pitfalls here between interpreters and compilers
 | that need to be explored.

SLIB takes the opposite approach of completing support by
implementations to that needed by the library system and programming
generally (see "Universal SLIB procedures"

SLIB's approach presents a smaller burden to ones memory than having
to remember which implementation supports which feature.

 | * support procedural, syntactic, and data abstraction more fully by
 |    allowing programs to define hygiene-bending and hygeine-breaking
 |    syntactic abstractions and new unique datatypes along with
 |    procedures and hygenic macros in any scope;
 | define-macro would be a plus.  syntax-case would be a plus
 | (potentially).

SLIB supports defmacro, macro-by-example, macros-that-work,
syntactic-closures, syntax-rules, and syntax-case for all

 | new datatypes... record semantics would mean a cleanup of SRFI 9
 | and 57, not an entire rewrite, in my opinion.

SLIB has records (procedures) and SRFI-9.

 | ...
 | * In general, R^6RS should include building blocks that allow a wide
 |    variety of libraries to be written,
 | R5RS already allows this.

Yes; SLIB proves it.

More information about the r6rs-discuss mailing list