Disclaimer: If you absolutely love R6RS, think it is just the greatest thing since sliced bread, and look back on R5RS as the dreary chronicles of an unenlightened dark age, you are guaranteed to disagree with the points brought up herein.  But maybe you have your doubts.  Maybe you wonder if everything was handled properly, or if maybe tripling the total length of the specification from 50 pages to 161 was a bad move.

And you may be right to doubt.  R6RS was only ratified by 65.7% of voters.  Of the 13 respondents to a survey of Scheme implementors, only 3 expressed an intention to support R6RS, and 2 registered their outright rejection of the standard, with Felix Winkelmann of Chicken Scheme saying flat out “R6RS must die.”

It’s sad.  Scheme is such a beautiful language. I began my Lisp forays with Common Lisp, but was quickly drawn away by the unparalleled purity and simplicity of Scheme.  I would code everything in Scheme if I could.  And part of what makes Scheme such a wonderful base to build upon is its philosophy of small, orthogonal features that can be composed into novel and interesting shapes.

The Problem

(As I See It)

R6RS strays from this way. It tries to deliver too much, and a lot of what it provides would be better implemented as an optional library on top of the Scheme base.  If you want a language that provides you with everything under the sun you can use Python, or if you just can’t bring yourself to give up the parentheses, Common Lisp is that way.

While I agree that Scheme could use a few more features, I believe that R5RS is much more versatile than it was given credit for.  Undoubtedly it has a few rough spots, but I think that they can be resolved with much fewer changes than R6RS inflicted upon the language.

Supporting my point, the section of R6RS devoted to libraries is the same length as the entire language overview.  Gone are the days when the entirety of Scheme (with the possible exception of continuations, which still give me trouble) could be learned in a day or two.  Understanding the semantics of the library system seems like such a daunting task that many neophytes could be turned away altogether.

But all this complexity doesn’t really gain us as much as we might think. As I see it, the main features of R6RS worth getting excited over are:

• A standardized library system
• Unicode support
• The ability to use it in script files

My Proposal

I wonder if maybe we should just add a few small changes to R5RS.  Nothing extravagant, just the bare minimum necessary to implement all the goodies that R6RS promised us.  We need a point upgrade to R5RS.  An R5.1RS.

Goals:

I used several criteria while brainstorming possible modifications to the R5RS Scheme language. I wanted them to be simple to understand, easy to implement, and genuinely useful in a variety of contexts.

1. Simplicity – The proposal defines the most minimal set of changes that will allow the desired functionality to be implemented in a portable, standard way.
2. Generality – The proposed changes need to be useful in many situations, not just for aping functionality already defined in R6RS.
3. Competition – The changes should not dictate any particular way of using them, they should simply make a few things possible that were not before.  This allows people to make use of the building blocks in their own ways, in the hopes that the best solution will be the one that ultimately wins out.

Proposed Changes:

My proposal defines four modifications.  Taken together, they will allow for the creation of portable, elegant library and module systems, allow Scheme to be used for system scripts in a standard way, and make it easier for people to write Scheme code in languages with alphabets outside of standard ASCII.

1. Define all Scheme programs to be UTF-8 encoded Unicode.
   • Rationale:  Unicode is becoming more and more prevalent as people all around the world begin to use computers, and our programming languages should reflect this fact.  UTF-8 should be the encoding of choice because of its ASCII transparency.  Any other encoding would require conversion before it would be editable.
2. Define a SCHEME-IMPLEMENTATION function, which returns a pair of (SCHEME-NAME . VERSION). SCHEME-NAME will be a symbol representing the name of the currently running implementation, and VERSION will be a number corresponding in some way to the version of the implementation.
   • Rationale:  Most implementation of Scheme provide some additional functionality above and beyond what is explicitly required by the R5RS spec. To allow portable libraries to make use of this functionality where it is available, some straightforward mechanism should be made available for libraries to determine what functions are available to them.  This approach avoids the difficulties of actually providing functions to determine what extensions are available, at the expense of requiring some amount of manual porting by library creators.
3. Define ‘#!’ to be a quotation symbol when encountered at the beginning of a line of text.
   • Rationale:  Scheme can only stand to gain from becoming more useful as a general-purpose scripting language.  Allowing Unix shebangs to be placed in the source  file will aid this goal, and since many Schemes already allow files to be executed when passed as command line arguments, the modifications needed are minimal.  Requiring that the symbol only be quoting at the beginning of a line helps to avoid inadvertent breakage of programs which may use those characters as identifiers, as identifiers are generally preceded either by an opening parenthesis, or whitespace.
4. Modify the definition of the LOAD function to state that it shall return a list containing the return values of all top-level forms in the loaded file.  This list will of course include, if applicable, the lists returned by other LOAD functions in the file.
   • Rationale:  The design of a module system requires that some provision be made to allow it to handle the code inside of modules.  The only portable way this can be achieved currently would require the use and modification of a global variable.  While it may be possible to account for variations in return values from many existing interpreters, it would be much nicer to be able to expect some sort of standard return values from the function.

Going Forward

Implementation  Considerations

The SCHEME-IMPLEMENTATION function should be relatively straightforward to support in any implementation.  It simply needs to return a pair of values, and this should be well within the capabilities of any popular implementation.  On the other hand, this could be implemented as an external library through some fancy checking of various unstandardized features of the language, but this solution is unappealing in the long term.

The LOAD function should be relatively easy to modify, but this may be rendered difficult by current implementations’ differing usage of the return value.  If enough implementations provide some sort of mechanism to retrieve at least one value from the loaded file, that may suffice to program a good module system.  As with the SCHEME-IMPLEMENTATION function, though, it would be nice to have a standard behaviour to expect.

The difficulty of implementing the new quoting form may vary, but should be simple enough in all but the most arcane of hand-coded parsers.  After all, Scheme already requires that ‘;;’ be recognized as a quoting form, and it shouldn’t be that much harder to define ‘#!’ similarly.

The Unicode point is possibly the hardest, and also maybe the most worthy of deferring until later.  On the one hand, few could say that there would be no use to adding it as an expected feature of the language, but on the other hand, it is hardly necessary to consider it alongside the other more trivial modifications suggested herein.  Yet another consideration, of course, is the general desirability of Unicode support to a Scheme implementation.  Even if it is not required that Unicode be supported, it is still likely that more and more languages will support it as time progresses.

Building Blocks

The LOAD and SCHEME-IMPLEMENTATION modifications suggested, while individually rather small, together allow significant progress to be made in the areas of portability and versatility for the Scheme language.  With the use of the newly-defined return values for the LOAD function, new module systems can be written with ease.  An easy to use, standardized mechanism for determining the current implementation allows portable libraries to be written with ease, by allowing them to know ahead of time what additional functions and capabilities are provided to them, without any of the roundabout methods currently required.  Adding the new commenting form makes it laughably easy to use Scheme as a scripting language on a level with Python, Perl, or Bash scripts.

Wrapping Up

I realize that my knowledge of Scheme is much more limited than many, so I ask you, Internet, do these recommendations seem like a sensible idea?  Are there issues that I simply don’t realize inherent to what I suggest?  Do I simply fail to understand the difficulty of implementing these suggestions?

I think that my ideas could work.  I really believe that these handful of little changes could ease the way for a whole new level of innovation and exploration with Scheme.  With the ability to easily implement new designs for module systems and libraries, I fully expect to see Scheme surpass the meager capabilities of Common Lisp’s ASDF, and then keep going.

I believe that this is worth a shot.  Any Scheme implementors out there who would be willing to give it a try?  If no one wants to implement it themselves, I fully understand, and have only one further question:

Would you be willing to let me give it a shot?