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.
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
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.
Why bytevector-u8-ref and bytevector-u8-set! rather than just
bytevector-ref and bytevector-set!
_______________________________________________ Scheme-reports mailing list Scheme-reports@x http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports