• Home
• All tickets
• All wiki pages

Source for ticket #536

cc

changetime

2013-07-07 03:20:44

component

WG1 - Core

description

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.

id

536

keywords

milestone

owner

alexshinn

priority

major

reporter

cowan

resolution

wontfix

severity

status

closed

summary

R6RS and R7RS libraries should be made closer

time

2013-05-20 00:11:52

type

defect

Changes

Change at time 2013-07-07 03:20:44

author

cowan

field

comment

newvalue

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

oldvalue

4

raw-time

1373142044410382

ticket

536

time

2013-07-07 03:20:44

Change at time 2013-07-07 03:20:44

author

cowan

field

resolution

newvalue

wontfix

oldvalue

raw-time

1373142044410382

ticket

536

time

2013-07-07 03:20:44

Change at time 2013-07-07 03:20:44

author

cowan

field

status

newvalue

closed

oldvalue

new

raw-time

1373142044410382

ticket

536

time

2013-07-07 03:20:44

Change at time 2013-05-21 01:40:04

author

cowan

field

comment

newvalue

See also my comment to #533.

oldvalue

3

raw-time

1369075204240921

ticket

536

time

2013-05-21 01:40:04

Change at time 2013-05-21 00:32:25

author

cowan

field

comment

newvalue

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 [http://www.r6rs.org/final/html/r6rs-lib/r6rs-lib-Z-H-13.html#node_sec_12.6 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 [wiki:WG1Ballot2 second ballot], where we chose `module`, and [wiki:WG1Ballot4Results 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.

oldvalue

2

raw-time

1369071145501630

ticket

536

time

2013-05-21 00:32:25

Change at time 2013-05-20 12:08:36

author

cowan

field

comment

newvalue

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.

oldvalue

1

raw-time

1369026516300625

ticket

536

time

2013-05-20 12:08:36