Slashdot Mirror
R7RS Scheme Progress Report
John Cowan recently gave a talk on the progress of R7RS (slides), the next revision of the Scheme language
standard, at LispNYC. After the R6RS debacle,
the community stepped back and is now basing the next standard on R5RS;
the work has been split into two languages — R7RS-Small and
R7RS-Large. The first
working group is preparing to issue a final draft
of the R7RS-Small language (PDF; clocking in at 73 pages vs.
R5RS's 50) within the next few weeks. Read on for a summary of the
planned changes to R7RS (more or less in the order of presentation).
The talk details a number of improvements over R5RS and R6RS, and is
divided into two portions. The majority of the talk discuses the
status of the small language, with the last portion giving a quick
update on the future intent of the large language group.
First on the list of major new features is a mandatory library system designed to be easily implemented atop existing module systems. R6RS's library system proved to tackle too much at once and be incompatible with everything already in a use (a persistent concern in the design of the R7RS-Small language). The R7RS system, on the other hand, is static, simple, and just powerful enough to promote implementation of portable libraries.
Exceptions are stripped down from R6RS (which proved too incompatible with existing implementations for practical use). guard (similar to try...catch in other languages) and with-exception-handler are supported: the latter runs the handler in the context from which the error was triggered (permitting recovery from the error like invoke-restart ) Unlike r6rs, exceptions lack a strictly defined hierarchy and can be any object (you could e.g. throw 4 if you really felt like it).
Dynamically scoped variables, in the form of parameters, are now part of the standard. Unlike Common Lisp special variables, parameters are first-class objects bound to expressions rather than symbols that are declared dynamically scoped. For reasons of simplicity it was decided to make parameters immutable (i.e. any "mutation" has to be done by rebinding). This has the (intentional) side-effect of making parameters play more nicely with threads (when mutation is permitted, setting a parameter that has not been rebound in the current thread requires synchronizing all threads and can have unexpected results).
As expected, R7RS includes bytevectors to complement strings. The small language standard only permits accessing bytevectors as ordered sets of unsigned 8-bit values (the large language standard will offer more flexible access). Binary I/O is implemented via a set of parallel procedures (open-binary-input-file vs. open-input-file, etc.) in contrast to the incredibly complicated dual binary/text ports provided by R6RS. Additionally, string and bytevector ports similar to SRFI-6 are provided instead of the incompatible string ports provided by R6RS.
Taylor Campbell noted that integer division in most languages is insufficiently expressive, and so R7RS will provide Euclidean division and centered division in addition to the usual suspects. Mathematicians rejoice!
As with R6RS, Unicode support is mandated. Unlike R6RS, the only characters that must be supported are those present in ASCII. For supported characters, Unicode case mapping and normalization are mandatory. One interesting diversion from Unicode and R6RS is that string order comparison is implementation-dependent: this gives implementers latitude with the internal encoding of strings.
Any user of Scheme knows that the language strives for consistent and obvious names for bindings. R7RS furthers this goal by resolving the long-standing inconsistency with core data structure creation, copying, mutation, mapping, etc. Lists, strings, and vectors now have a consistent set of each: make-TYPE, TYPE-copy, TYPE-set!, etc. Conversion procedures between all three types are also provided.
Finally, number of minor improvements were made. Most notable: record types are compatible with SRFI-6 (widely in use today); case sensitivity is the default (with optional insensitivity via include-ci); s-expression and nested block comments were added; IEEE infinities and NaNs have read syntax; strings may contain C-style escape sequences; Common Lisp circular list notation is supported; and common extensions to syntax-rules were standardized.
The final 20 minutes of the talk were about the status of R7RS-Large.
The R7RS Large language is currently on hold, mostly because all the small language members are on the large language committee as well, so there is a lack of time to work on both simultaneously. Work is planned to resume upon release of the final draft of the small language. Some work, however, has been completed.
The main focus of R7RS-Large is providing Scheme "with batteries included." John Cowan started the process by looking beyond the Lisp and Scheme communities (Python is mentioned) to figure out which libraries modern programmers expect their language to include.
This resulted in a list of around 250 packages that was narrowed down to around 80 packages through an initial voting process. It was decided then than some desirable packages (e.g. a foreign function interface) had to be omitted due to complexity. It is expected that implementers will continue experimenting and gradually come to a consensus on the larger packages using the existing SRFI process, and perhaps another revision of the standard down the road.
Of the packages planned for inclusion, the most prominent are: networking, threads, regular expressions, delimited continuations, URI handling, date and time parsing/arithmetic/formatting, hash tables, ambient environment access, file system directory access, gettext (i18n support), and pattern matching.
Most will be optional; packages will only be made mandatory if a number of the other packages require them. A compliant R7RS-Large implementation will only have to either provide a package fully or not at all (half implementations are forbidden).
Interestingly, R7RS large with all packages will be even larger than Common Lisp.
To avoid getting bogged down in stylistic discussions, a decision was made to focus on functionality above other concerns. The resulting packages may not be aesthetically pleasing to everyone, but will provide useful functionality. Users who disagree with naming, scope of functionality, argument ordering, etc. will be free to use the library system to import only the bindings they want, rename functions, wrap things into the style they want, etc. Basically, a compromise between the MIT approach and "Worse is Better" is being sought.
Here a call for volunteers is made: Since the focus will be on functionality over pure aesthetics, developers outside of the Lisp and Scheme communities are actively encouraged to participate in the R7RS-Large language process. No fixed time commitment would be required; the goal is to get a lot of people involved with a few core members maintaining momentum and guiding the process. The R7RS-Large language is most definitely a language designed by and for developers. So, make your voice heard!
Overall R7RS is shaping up to be the standard R6RS should have been (which, of course, could not have happened without the lessons of R6RS). The split between an elegant core language with each design issue meticulously fretted over and voted upon and a looser library standard should, hopefully, result in a core language that will stand the test of time with a standard library that can be used to get actual work done.
First on the list of major new features is a mandatory library system designed to be easily implemented atop existing module systems. R6RS's library system proved to tackle too much at once and be incompatible with everything already in a use (a persistent concern in the design of the R7RS-Small language). The R7RS system, on the other hand, is static, simple, and just powerful enough to promote implementation of portable libraries.
Exceptions are stripped down from R6RS (which proved too incompatible with existing implementations for practical use). guard (similar to try...catch in other languages) and with-exception-handler are supported: the latter runs the handler in the context from which the error was triggered (permitting recovery from the error like invoke-restart ) Unlike r6rs, exceptions lack a strictly defined hierarchy and can be any object (you could e.g. throw 4 if you really felt like it).
Dynamically scoped variables, in the form of parameters, are now part of the standard. Unlike Common Lisp special variables, parameters are first-class objects bound to expressions rather than symbols that are declared dynamically scoped. For reasons of simplicity it was decided to make parameters immutable (i.e. any "mutation" has to be done by rebinding). This has the (intentional) side-effect of making parameters play more nicely with threads (when mutation is permitted, setting a parameter that has not been rebound in the current thread requires synchronizing all threads and can have unexpected results).
As expected, R7RS includes bytevectors to complement strings. The small language standard only permits accessing bytevectors as ordered sets of unsigned 8-bit values (the large language standard will offer more flexible access). Binary I/O is implemented via a set of parallel procedures (open-binary-input-file vs. open-input-file, etc.) in contrast to the incredibly complicated dual binary/text ports provided by R6RS. Additionally, string and bytevector ports similar to SRFI-6 are provided instead of the incompatible string ports provided by R6RS.
Taylor Campbell noted that integer division in most languages is insufficiently expressive, and so R7RS will provide Euclidean division and centered division in addition to the usual suspects. Mathematicians rejoice!
As with R6RS, Unicode support is mandated. Unlike R6RS, the only characters that must be supported are those present in ASCII. For supported characters, Unicode case mapping and normalization are mandatory. One interesting diversion from Unicode and R6RS is that string order comparison is implementation-dependent: this gives implementers latitude with the internal encoding of strings.
Any user of Scheme knows that the language strives for consistent and obvious names for bindings. R7RS furthers this goal by resolving the long-standing inconsistency with core data structure creation, copying, mutation, mapping, etc. Lists, strings, and vectors now have a consistent set of each: make-TYPE, TYPE-copy, TYPE-set!, etc. Conversion procedures between all three types are also provided.
Finally, number of minor improvements were made. Most notable: record types are compatible with SRFI-6 (widely in use today); case sensitivity is the default (with optional insensitivity via include-ci); s-expression and nested block comments were added; IEEE infinities and NaNs have read syntax; strings may contain C-style escape sequences; Common Lisp circular list notation is supported; and common extensions to syntax-rules were standardized.
The final 20 minutes of the talk were about the status of R7RS-Large.
The R7RS Large language is currently on hold, mostly because all the small language members are on the large language committee as well, so there is a lack of time to work on both simultaneously. Work is planned to resume upon release of the final draft of the small language. Some work, however, has been completed.
The main focus of R7RS-Large is providing Scheme "with batteries included." John Cowan started the process by looking beyond the Lisp and Scheme communities (Python is mentioned) to figure out which libraries modern programmers expect their language to include.
This resulted in a list of around 250 packages that was narrowed down to around 80 packages through an initial voting process. It was decided then than some desirable packages (e.g. a foreign function interface) had to be omitted due to complexity. It is expected that implementers will continue experimenting and gradually come to a consensus on the larger packages using the existing SRFI process, and perhaps another revision of the standard down the road.
Of the packages planned for inclusion, the most prominent are: networking, threads, regular expressions, delimited continuations, URI handling, date and time parsing/arithmetic/formatting, hash tables, ambient environment access, file system directory access, gettext (i18n support), and pattern matching.
Most will be optional; packages will only be made mandatory if a number of the other packages require them. A compliant R7RS-Large implementation will only have to either provide a package fully or not at all (half implementations are forbidden).
Interestingly, R7RS large with all packages will be even larger than Common Lisp.
To avoid getting bogged down in stylistic discussions, a decision was made to focus on functionality above other concerns. The resulting packages may not be aesthetically pleasing to everyone, but will provide useful functionality. Users who disagree with naming, scope of functionality, argument ordering, etc. will be free to use the library system to import only the bindings they want, rename functions, wrap things into the style they want, etc. Basically, a compromise between the MIT approach and "Worse is Better" is being sought.
Here a call for volunteers is made: Since the focus will be on functionality over pure aesthetics, developers outside of the Lisp and Scheme communities are actively encouraged to participate in the R7RS-Large language process. No fixed time commitment would be required; the goal is to get a lot of people involved with a few core members maintaining momentum and guiding the process. The R7RS-Large language is most definitely a language designed by and for developers. So, make your voice heard!
Overall R7RS is shaping up to be the standard R6RS should have been (which, of course, could not have happened without the lessons of R6RS). The split between an elegant core language with each design issue meticulously fretted over and voted upon and a looser library standard should, hopefully, result in a core language that will stand the test of time with a standard library that can be used to get actual work done.
So what happened to R2D2?
It's been quite a while since the summary made so little sense to me that I didn't bother to read the article. Sometimes, I like to be reminded of how much I just don't know.
Thank you Scheme Language Standard!
Chibi-scheme is a nice C-based implementation following the R7RS-Small standard closely -- the author is the R7RS-Small committee chair.
Don't. It's increasingly harder to be a polymath, even if you confine your domain to technology, perhaps even in CS.
You may have inferred that Scheme is related to Lisp ; they call it a "dialect", stretching a bit the analogy with human languages. Common Lisp is another, and I had brief run-ins with both while peeking under the hood of two great projects: Maxima and the gEDA suite. They left me impressed and determined to learn the language, as soon as I had the mood/time to wrap my easily-distracted brain around it.
This post contains no rudeness or derision of any kind. All arguments are friendly. Terms and exclusions may apply.
There is a functional language called Scheme. It is a minimal LISP with some advanced features and noted for having a very small specification. The current version is (deep breath) R6RS. Don't panic; that just means Revised(6) Report (on the algorithmic language) Scheme. The previous version was R5RS and the next is R7RS. Yes, you could drop all the consonants and have the same result, but that doesn't occur to academics.
The gist of the story is that R6RS isn't being adopted by implementations (scheme has many divergent implementations) and that R7RS is being worked on with a higher rate of adoption in mind.
And yes, if you have spent much time around Slashdot and taken an interest in the technical topics (as opposed to the political controversies) you are expected to know enough of this to follow the summary. Not that it was written all that well...
Lurking at the bottom of the gravity well, getting old
It's what Slashdot is supposed to be.
If you're having problems, then maybe you should go and read the first 218 pages:
http://en.wikipedia.org/wiki/Scheme_(programming_language)
http://en.wikipedia.org/wiki/R6RS#R6RS
http://www.r6rs.org/
"Was not one of scheme original goals to a have small and extendable language and let's it's users use the library they want ?" That's *exactly* what they're getting: a small, meticulously crafted kernel language, upon which you can build whatever you like!
Interested in avoiding the fragmentation of a thousand non-standard libraries that do more or less the same thing? Got you covered there, too! R7RS-Large is a portable set of libraries for your applications. Fragmentation, be gone!
From the summary, the high-profile libraries include "networking, threads, regular expressions, delimited continuations, URI handling, date and time parsing/arithmetic/formatting, hash tables, ambient environment access, file system directory access, gettext (i18n support), and pattern matching." Yeah, that's going to be bigger than Common Lisp. On the other hand -- and I say this as a CL user -- it's almost a little sad, given the side of the Common Lisp standard, that so many of those features are left unstandardized.
Yes, I agree. There is such a blind reverence to the CLHS and "[just grab a lib|roll your own] is so easy, why bother?" is so prevalent that it seems that many in the CL community don't even conceive of the possibility of an updated standard, just delving into what nuances can be extracted from the current spec for edge cases and optimization conditions. Plus, many of the libraries are something that a CL hacker banged together in his interactive sessions and aren't very robust or documented, but become ad-hoc standards simply because nothing else is out there. It's amazing that arguably the best functional/imperative/metaprogramming language out there has formed such a terrible ecosystem (The Lisp Curse, etc).
Good on Scheme for moving forward, and while I didn't watch the videos, it sounds like much of this new functionality is standardizing on libraries instead of burdening the core too much.
The numbers in R5RS, R6RS, and R7RS are really superscripts: R5RS stands for "the Revised Revised Revised Revised Revised Report on the Algorithmic Language Scheme".
Personally I think that joke's pretty worn out, but the Working Group decided otherwise.
Either I misspoke or someone misheard. "Environment enquiries" is a Common Lisp term for functions that return things from the environment such as wall-clock time, internal time in jiffies, the name and version of the implementation, the name of the hardware and OS the implementation is running on, the host name, the working directory, the Unix environment variables, the command-line arguments, and so on. Most of these things wound up in R7RS-small one way or another already, but I didn' t know that when I made the package list.