On Fri, Jul 12, 2013 at 7:07 PM, Alex Shinn <alexshinn@gmail.com> wrote:
> 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.

Last I heard we (SC) asked you to produce the final draft.  I haven't
seen any email about that draft; did you send it to the SC?

> On Sat, Jul 13, 2013 at 2:34 AM, Chris Hanson <cph@chris-hanson.org> 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.

By any library you have written, anyway.  But I guess it doesn't
matter since even having two define-library forms in a single file,
the imports of the first shouldn't affect the second.

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

Yes, I get this, but I'm a little unhappy about introducing syntax
that isn't part of the normal language.  The model of a single
namespace for all bindings and syntax is a pretty compelling one, and
I would be happier if the import and define-library syntax was
integrated into that namespace rather than being special.  If that
were the case then the workaround you outline for import would be
unnecessary, plus the model would be simpler.

But as you say, we can defer these questions to the next round.

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

It would be nice to have a sentence making that explicit.

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

Well, if the library is optional, and the implementation doesn't
provide that library, strings _are_ immutable in that implementation.
That would be a useful change.

Thanks for taking the time to address my much-too-late comments!

Chris

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports