[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

> 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

> 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

> "<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:


> "Modules provide a way to organize Scheme programs into reusable parts
> with explicitly defined interfaces to the rest of the program. This
> section [...]"


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


> 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