[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] Issues from read-through
Chris Hanson scripsit:
> Here are a bunch of issues I identified, some editorial and some
> substantive, while I read the draft report. Please take care of the
> editorial issues; it's probably too late to do anything for the other
> issues, but I've included them for the record.
These are solely my responses.
> Section 1.3.3, paragraph 2:
>
> ...; for example, <expression> stands for any string of
> characters which is a syntactically valid expression.
>
> Change "which" to "that".
This is a grammatical superstition rather than a rule. See
<http://stancarey.wordpress.com/2011/10/18/that-which-is-restrictive/>
for details.
> Section 2.1, paragraph 3:
>
> Note that || is a valid identifier that is different from any
> other identifier.
>
> A tautology; ANY identifier is different from ANY OTHER
> identifier. Either drop this sentence or change wording to have
> some meaning.
Of course you are correct; this sentence was meant to be helpful rather
than defining (the actual definitions are in section 7.1).
> Section 2.3, paragraph 1:
>
> Note that a sequence of two or more periods is an identifier.
>
> Is |.| an identifier? Maybe clarify here.
Same answer. Just trying to show that while . is not an identifier,
.. and ... and .... etc. are identifiers. And yes, |.| is an identifier.
> Section 2.4, paragraph 1:
>
> It is an error if <n> is not a sequence of digits.
>
> Should be "non-empty sequence".
Picky, picky, picky. The formal syntax controls.
> Section 3.1, paragraph 2:
>
> The most fundamental of the variable binding constructs is the
> lambda expression, because all other variable binding
> constructs can be explained in terms of lambda expressions.
>
> Except top-level bindings.
I believe this is worth fixing and will add it to the errata.
> Section 3.1, paragraph 3:
>
> If there is no binding of the identifier whose region contains
> the use, then the use refers to the binding for the variable
> in the global environment.
>
> Here, and in many other places, the word "global" is inaccurate
> and misleading. There is no global environment in Scheme as
> described in this report; only top-level environments, one per
> program or library.
There is also the interaction environment, which controls what happens at the
REPL. "Global" is a synonym for "outermost in the current context",
though we probably should have said so.
> Section 3.2, paragraph 1:
>
> Should error? and/or promise? be added to this list?
No, they are not guaranteed disjoint.
> Section 4.1.4, bullet item 2:
>
> <variable> The procedure takes any number of arguments; when
> the procedure is called, the sequence of actual arguments is
> converted into a newly-allocated list, and the list is stored
> in a fresh location that is bound to <variable>.
>
> It would be nice if it were an error to modify this list. That
> would give implementations some useful flexibility.
It would indeed be nice; alas, it is not Scheme. IMHO there should have
been privileged accessors to an opaque rest-argument-object rather than
having Scheme-the-language tied to the standard Scheme data structures,
but it's too late now.
> Section 4.3.2, paragraph 3:
>
> I wish we had never allowed vector patterns and templates. That's
> just a bad idea, adding additional ways to write things that
> provides no real expressive power.
>From what I understand, these are necessary in order to allow
quasiquotation of vectors to be implemented using syntax-rules. I myself
don't understand how the quasiquote macro works, so I can't affirm this.
> 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.
I can only respond vaguely by saying that import and define-library are
not really bound to anything: they are recognized verbatim, as the names
of library declarations are. In a sense they are outside the Scheme
scheme of things.
> 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.
This is the same freedom that R6RS allows. I think it's probably
a mistake (libraries should be loaded once and only once per program
execution), but we didn't want to be semantically incompatible with R6RS
in this respect.
> Section 6.6, paragraph 5:
>
> Case is significant in #\<character>, and in #\<character
> name>, but not in #\x<hex scalar value>.
>
> It seems to me that #\<character name> should be case insensitive
> and limited to ASCII. In addition, it would be desirable if the
> character names were the Unicode names, replacing spaces with
> hyphens (or underscores), with the addition of the historical
> character names where those differ.
We voted on the Unicode names as well as the W3C entity names as
non-normative sources, and decided not to say anything. Some of the
Unicode names, however, are awfully long: consider LATIN SMALL LETTER N
WITH LONG RIGHT LEG, or ARABIC SYMBOL THREE DOTS POINTING DOWNWARDS ABOVE.
Making them case-sensitive allows TeX-style and W3C-style contrasts like
#\Iota (capital iota) vs. #\iota (small iota). I agree that ASCII-only
might have been a sensible restriction.
> 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.
A boxed bytevector is usable, however, though expensive in terms of time
and space. Mutable strings were the thing I most wanted to get rid of,
but my sense of the WG was that removing string mutability, which is
required by IEEE, was too big a change.
> Section 6.9:
>
> Why bytevector-u8-ref and bytevector-u8-set! rather than just
> bytevector-ref and bytevector-set!
In the large language there will be bytevector-u16-ref and many others.
Bytevectors in the large language are a sort of hybrid between
simple blobs and u8vectors. There seemed little point in providing
bytevector-ref in the small language and a synonymous bytevector-u8-ref
in the large language.
> Section 6.10:
>
> Given that there are operations for all sequence types except
> bytevector, why was the latter excluded?
Same answer: it is more of a blob type than a sequence type.
The large language will allow treating it as many different sequence
types, which would have been overkill for the small language. See
<http://trac.sacrideo.us/wg/wiki/NumericVectorsCowan> for a detailed
proposal.
--
Do what you will, John Cowan
this Life's a Fiction cowan@x
And is made up of http://www.ccil.org/~cowan
Contradiction. --William Blake
_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports