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 <[email protected]> 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
_______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
