[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] Draft 3 Comments: Chapter 5
Denis Washington scripsit:
> "Some implementations of Scheme use an initial environment in which
> all possible variables are bound to locations, most of which contain
> undefined values. [...]" I am not sure if this is needed. I know,
> it's from R5RS and not added to the draft, but this sounds more
> like the old approach of a Scheme "report" in the original sense
> (as in, observation of the state of the art) rather than its modern
> interpretation as standards document.
I think it's unavoidable. Currently, Racket, Gauch, MIT, Gambit,
Scheme48/scsh, Guile, SISC, SCM, Ypsilon, STklos, SigScheme, Scheme 9
complain about the attempt to set! an unbound variable, whereas Chicken,
Kawa, Chibi, Chez, Ikarus, Larceny, Mosh do not. Getting all of either
group to change would be too painful.
> I already noticed something similar in chapter 2 (the title "Lexical
> conventions" rather than "rules" or "syntax", or "The precise rules
> for forming identifiers vary among implementations of Scheme [...]" in
> section 2.1).
This is, so to speak, even more true in R7RS, given the optional-Unicode
design.
> Rather than saying that the transformer should be a syntax-rules
> form, it might be preferable to say that it should be a macro
> transformer but that syntax-rules is the only one defined in
> this report. Later, this can be augmented with a reference to
> "syntax-case" in the big language.
Or whatever we get. Currently, WG2 voted down syntax-case (by one
vote).
> The added paragraph regarding ambiguous definitions is very, very hard
> to understand; the sentences are not particularly well digestible. But
> I admit that it is very hard to explain. ;) A proposal:
>
> "Macros may expand into (syntax) definitions in any context that
> permits them. However, it is an error for a (syntax) definition to
> define an identifier whose binding must be known to determine the
> meaning of the definition itself, or of any preceding definition that
> belongs to the same group of internal definitions. Similarly, it is
> an error for an internal definition to define an identifier whose
> binding must be known to determine the boundary between the internal
> definitions and the expressions of the <body> it belongs to. For
> example, the following are
I'm not completely happy with this, but I've adopted it as an
improvement on what we had.
> It would be nice if the last example would use a more descriptive
> macro name than "foo". For the fun of it, one could make it a macro
> that resembles CL's "defun" and call it that. Also, I would remove
> the "let" and the last body expression, as IMO it is not needed to
> illustrate the boundary problem (correct me if I'm wrong).
Since it's a counterexample rather than an example, I'm disinclined to
fiddle with it.
> The header and the first paragraphs uses "record-type" with a hyphen
> while the rest of the section's text uses the whitespaced "record
> type". This should be consistent. I like the latter much better.
Fixed on trunk.
> I feel that the introductory paragraph could be improved. It doesn't
> really explain what records / record types actually are. A proposal:
>
> "Record type definitions are used to introduce new data types, called
> _record types_. The values of a record types are called records and
> are aggregations of zero or more _fields_, each of which holds a
> single value (similarly to a variable)."
I implemented a close variant of that, saying that a field is a
location.
> "<pred> is a predicate [...]" should be "<pred> is bound to a
> predicate [...]". Likewise "Each <accessor name> is [...]" and "Each
> <modifier name> is [...]".
Fixed on trunk.
> The "kons" example should begin with a phrase signalling that an
> example follows: "For instance, the following definition [...]"
Fixed on trunk.
> The report doesn't introduce the notion of a "namespace", yet it is
> used in the introductory sentence. I think that part of the sentence
> can just be dropped. I also don't like "encapsulate programs"; it's
> not a vey useful explanation IMO. A proposal:
Adopted.
> "Modules provide a way to organize Scheme programs into reusable parts
> with explicitly defined interfaces to the rest of the program. This
> section [...]"
Adopted.
> There is another instance of the un-introduced "form" term here
> ("[...] read all top-level forms from the files [...]") which
> probably stems from the fact that this section is mostly took from
> R6RS.
Fixed on trunk.
> "The difference between the two is that include-ci reads each file as
> if it began with the #!fold-case directive (see section 2.1), while
> include does not."
Adopted.
> In the paragraph about "cond-expand", I would rather use the term
> "implementation environment" than "platform", but your mileage may
> vary.
The words "platform or" removed.
> As section 5.5 has no other subsection than 5.5, it would seem to make
> sense to just put all of 5.5.1 into 5.5 directly.
There is also 5.5.2 Module Examples.
> That's it for this chapter. As always, I sincerely hope that my
> comments are helpful for you.
They are!
--
Well, I have news for our current leaders John Cowan
and the leaders of tomorrow: the Bill of cowan@x
Rights is not a frivolous luxury, in force http://www.ccil.org/~cowan
only during times of peace and prosperity.
We don't just push it to the side when the going gets tough. --Molly Ivins
_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports