Re: [Scheme-reports] Issues from read-through

Thanks for the comments, Chris.

We've released the final draft, so editorial changes will

have to go in as errata, or left to R8RS. I've responded

to the more substantial points inline.

On Sat, Jul 13, 2013 at 2:34 AM, Chris Hanson <cph@x> wrote:

Section 5.2, paragraph 1:

What if a library exports the name "import"? Or "define-library"?
At a minimum, there should be some text regarding this case. One
obvious solution is to ban their use as identifiers. Another,
which I prefer, is to change the "empty" initial environment to
contain only the standard bindings for those identifiers.

There's no conflict with define-library, which is not exported

by any library.

Technically import is not a binding either - the draft reads:

A Scheme program consists of one or more import declarations

followed by a sequence of expressions and definitions.

There is an ambiguity if you import a binding for "import" and

the next top-level binding is of the form (import ...), which could

be either an import declaration or a reference to the imported

binding. The intention and obvious implementation is the latter.

There was some debate about this - allowing only a single initial

import declaration would have removed the ambiguity.

As is, simple way to avoid ambiguity is to end all import

declarations with a noop top-level _expression_:

(import (library exporting import)) ; declaration

'no-more-imports

(import (yada yada)) ; imported binding

Section 5.6.1, last paragraph:

Regardless of the number of times that a library is loaded,
each program or library that imports bindings from a library
must do so from a single loading of that library, regardless
of the number of import declarations in which it appears.

This avoids saying what happens if two distict programs or
libraries import from the same library. Since a library can have
top-level side effects, this must be specified. Alternatively,
the report could forbid top-level side effects, but this gets
complicated pretty quickly and would be hard to prove in a
compiler.

There was much debate about this, but the standard

is written to be permissive of existing conventions. R6RS

in particular gives no guarantees as to the number of times

a library is loaded. The upshot is to avoid top-level side-effects

in portable code.

Section 6.7:

This would have been a good opportunity to provide for immutable
strings, and push the mutability procedures into an optional
library. The mutable-string design, which is my fault given that
I defined the string operations in RRRS, is in hindsight a real
mistake. There's no good reason for strings to be mutable, and
requiring them to be precludes many useful implementations, e.g.
a simple UTF-8 encoded bytevector.

I agree, but with backwards compatibility restrictions the

best we could do was move the operations to a library, so

strings themselves would still be mutable. Something for

R8RS.

Section 6.9:

Why bytevector-u8-ref and bytevector-u8-set! rather than just
bytevector-ref and bytevector-set!

The "bytevector" name changed a few times (ending in the

R6RS names since there was no reason to be different).

The original name was "blob", and the intention was that this

be a universal type for binary data, accessed in different ways

such as -u8-ref/set! in the core and -u16/u32/...-ref/set! in an

upcoming WG2 library. This is in contrast to SRFI-4 which

uses a separate homogeneous types. This was also a point of

much debate, but the core is still compatible with a renaming

of SRFI-4 u8vectors.

Alex