[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

I would tone down some of the language



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