[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] Draft 3 Comments: Chapter 5
Am 07.08.2011 07:10, schrieb John Cowan:
> 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 didn't object to the content, but was thinking about the style. I just
meant that as a standard, the document doesn't benefit from this
paragraph as it doesn't specify anything (it is completely informal), so
it could as well be removed. However, if we would also like to keep the
notion of the document as a "report" - as in, a description of the
current state of Scheme implementations - it makes sense to keep the
sentence. I think there should just be a consent as to whether we want
that or not, to make things consistent. (Currently, there are sections
such as 2.1 which somewhat mix "prescriptive" and "descriptive"
statements, without clearly drawing a line between the two.)
>> 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.
Neither am I, but I am happy that I could help.
>> 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.
Well, no other part of the report uses an extra section for examples, so
pulling everything into 5.5 would increase consistency.
>> That's it for this chapter.
As always, I sincerely hope that my
>> comments are helpful for you.
>
> They are!
Great to hear. :)
Regards,
Denis
_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports