2013/05/22

R7RS support

We don't have an official announcement yet, but it seems that R7RS is ratified. Yay! Great thanks to the WG members for long and hard work to realize it.

I couldn't participate in discussions as much as I did for R6RS mainly due to time constraints, but another reason is that I was generally happy about the drafts, unlike what I felt during R6RS development.

I don't hate R6RS; they have some parts I like (e.g. I/O system) and I expect them to be in R7RS-large. I just think R6RS was too ambitious; it tried so hard to plug all the loopholes that some of its parts were introduced prematurely, IMHO. R7RS-small isn't perfect; but it fixes some of the biggest shortcomings of R5RS and "good enough" to move on. I believe, in order to fix the remaining defects, it's better to wait quasi-standard SRFIs that are adopted by most active implementations. The standard can come later, merely to codify the de-facto and proven ways, as R7RS did for some SRFIs.

＊ ＊ ＊

The developlemnt HEAD of Gauche already has some R7RS support. If you invoke gosh as gosh -r7, it starts REPL with R7RS environment. Currently it implicitly imports all the R7RS-small libraries. You can also load files containing define-library form.

(The -r7 option only sets up the default behavior, and it's not that there's a distinct R7RS language mode. You'll be able to use R7RS library from Gauche code, and import Gauche library from R7RS code. Aside from the reader mode described below, the difference between R7RS and Gauche are merely namespaces.)

However, it's not quite ready yet to load portable R7RS libraries. The biggest obstacle is the lexical syntax---the \xNN; style escaping in strings and symbols are not supported yet, because of the backward compatibility problem. Gauche has been using \xNN (two-digits fixed, no semicolon terminator) style. It doesn't generally appear in the source code (the unicode escape, \uNNNN, is preferred), but it appears in datafiles dumped by write. Changing it would break existing datafiles, which would be a disaster.

There are also a few minor reader incompatibilities. For example, Gauche treats single quote as delimiters, so abc'def is parsed as a symbol abc and a list (quote def). In R7RS, this is a reader error.

My plan is to provide a few reader modes:

• Legacy Gauche: Completely backward compatible
• r7rs-compatible: Accepts both format, preferring r7rs when ambiguous
• r7rs-strict: Reject syntax that doesn't comply r7rs

There are also small number of unsupported library functions and syntaxes, which I'm implementing gradually at my spare time. See lib/r7rs.scm to check what aren't supported yet.

The high-level macro also need to be enhanced to comply R7RS. Internal define-syntax is yet to be supported.

＊ ＊ ＊

The R7RS import form works differently from Gauche's import. Gauche's one purely works on on-memory module objects and doesn't involve loading files. R7RS import is rather similar to Gauche's use, which is explained as require and (Gauche's) import.

I pondered a few options for some time: Overload import form with dual functionalities? Change Gauche's import so that it work like R7RS import? Finally I decided to implement completely separate forms. Gauche's import is mostly used in define-module form, which isn't R7RS, so I expect there's not much confusion. We can always rename Gauche's import to something like import-module in future.

Tags: r7rs, import