Email list hosting service & mailing list manager


I would tone down some of the language Ray Blaak 26 Jul 2008 18:58 UTC

I applaud this effort to simplify things. However, a reference document
should try and avoid the hints of past fights, tense emotions,
flamebait, etc.

In particular, this:
> Two days later, Dybvig proposed a "compromise" along those lines [11]
> that incorporated several artificial restrictions, apparently because
> Dybvig feared his compiler would be unable to generate efficient code
> for the general case. [12]
is better as:
> Two days later, Dybvig proposed a "compromise" along those lines [11]
> that incorporated several artificial restrictions, due to efficiency
> concerns for the general case. [12]
And this:
> Meanwhile, gratuitous design errors impede interoperation between
> procedural and syntactic layers, and several bogus claims about the
> inefficiency of higher order procedures were inserted into the very
> last public draft and were then ratified as part of the R6RS. [17]
is better as:
> Meanwhile, design errors impede interoperation between procedural and
> syntactic layers, and several invalid claims about the inefficiency of
> higher order procedures were inserted into the very last public draft
> and were then ratified as part of the R6RS. [17]
If necessary, put in a paragraph that addresses the efficiency issue
with higher order procedures directly, e.g. "we show that the efficiency
concerns related to higher order procedures are in fact not valid..."

Remove words like "bogus", "gratuitous", hints of sarcasm, etc.

Note that I am not saying you are incorrect with those words :-). It is
just that the communication of the ideas is more effective if the
reasons for things are made directly clear. When the disputes are long
forgotten, this document will still serve as an implementation
reference, and that is the purpose it should be optimized for.

Cheers,
Ray Blaak