| 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.
Received on Fri Aug 24 2007 - 22:08:37 UTC