[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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
(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

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

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.


Scheme-reports mailing list