[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"
http://swiss.csail.mit.edu/~jaffer/slib_2).

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
implementations.

 | 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