This site is a static rendering of the Trac instance that was used by R7RS-WG1 for its work on R7RS-small (PDF), which was ratified in 2013. For more information, see Home.

Ticket 536: R6RS and R7RS libraries should be made closer

2013-07-07 03:20:44
WG1 - Core
alexshinn
major
cowan
wontfix
source
closed
2013-05-20 00:11:52
defect

Michael Montague writes:

R6RS libraries without versions and import levels seem awfully close to R7RS libraries; could they be made closer to the same without losing the benefits of R7RS libraries? For example, assuming #535, I believe that the following would be a valid R6RS and R7RS library (ignoring library vs define-library keyword).

(library (stack) (export make push! pop! empty!) (import (rnrs)) (begin ;;; <----- all I did was add this to the example in section 7.3 of R6RS (define (make) (list '())) (define (push! s v) (set-car! s (cons v (car s)))) (define (pop! s) (let ([v (caar s)]) (set-car! s (cdar s)) v)) (define (empty! s) (set-car! s '()))))

This is a valid transformation even without #535, at least for an implementation that provides the (rnrs) library. The effect of #535 is to forbid multiple begin declarations; the existing draft already permits single ones.

The primary benefit of using a distinct keyword is to allow R6RS implementations to immediately reject R7RS libraries that they cannot process. R7RS implementations that don't provide the R6RS system libraries (such as Chibi) can also reject R6RS user libraries easily, but of course there is nothing to prevent R7RS implementations from accepting R6RS libraries as well, as Sagittarius does.

Michael Montague replies:

Right now, it is not possible to have a library which works in both R6RS and R7RS. If the define-library keyword was changed to library then some libraries would work in both R6RS and R7RS.

In the general case, no library can work exactly unchanged on both R6RS and R7RS systems because of the differences in the names and contents of the libraries they need to import. At the very least, each needs to import the base library, which means that an R7RS library will begin with (import (rnrs base)) and an R7RS library with (import (scheme base)). This difference is unavoidable, of course, since these libraries are quite distinct.

Using a distinct keyword makes portability of libraries between R6RS and R7RS impossible. I believe that normal error detection on R6RS systems should detect R7RS libraries (outside the common subset) as an error. And vice versa for R7RS systems. It seems like it would be reasonably easy for a system to decide that the error is likely caused by an incompatible library. And for systems that want to support both R6RS and R7RS, it seems like attempting to load the library first as R7RS and if that doesn't work then as R6RS would do the trick.

Quite so, but this is equally true if the libraries are (as they are today) syntactically distinct.

In short, having this difference helps humans and simple-minded classifiers and doesn't actually harm anyone that I can see. If you see further than I do, please help me here.

Michael Montague writes:

Having different keywords harms scheme users who want to write portable libraries. Today, a scheme user who wants to write portable libraries has to make a choice: use R6RS library or R7RS define-library.

In R7RS, at least, it's possible to segregate the code from the library declarations. R6RS systems that support include can do that too, or you can write include as a syntax-case macro. There's a sample definition in R6RS section 12.6. This also allows you to use the code on a pure R5RS system with no modules, or (as my sample implementations do) on an R5RS system like Chicken with its own module system.

Change to the same keyword, and the scheme user has a way to write portable libraries that work on as many scheme systems as possible now and into the future, including current R6RS systems and future R7RS systems.

Well, the WG will consider the question. It's been treated as a bikeshed issue so far. See #102 and the second ballot, where we chose module, and fourth ballot, where we changed it to define-library to be closer to R6RS without colliding with it.

The second sentence of the Charter for working group 1 is "The purpose of this work is to facilitate sharing of Scheme code." I believe this is a way to increase the sharing of Scheme code.

The base library problem is solvable. For instance, R7RS has the library (scheme r5rs). Since R6RS is based on R5RS, it should be easy to provide the same library on those systems.

I don't expect that R6RS users will tend to restrict themselves to the R5RS part of the system, though.

See also my comment to #533.

resolutionwontfix
statusnewclosed

The WG decided by unanimous consent to take no action on this ticket.