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

Re: A few more minor tweaks



Good luck with the hurricane!

On 10/30/12, David A. Wheeler <dwheeler@xxxxxxxxxxxx> wrote:
> Mark H Weaver:
>> The current draft says:
>> > Even some Lisp advocates, like Paul Graham, admit that they "don't find
>> > prefix math expressions natural" (http://www.paulgraham.com/pypar.html)
>>
>> That URL does not contain that quote.  This one does:
>>
>>   http://www.paulgraham.com/popular.html
>
> Whups!  Thanks for pointing that out, I'm not sure how the wrong URL got
> there.  Fixed in my local version, to be posted.
>
>> > 2. e{} => (e) when there are zero or more whitespace characters within
>> >    the braces; otherwise, e{...} => (e {...}). E.g.,
>> >    f{n - 1} => (f {n - 1}) => (f (- n 1)), and g{- x} => (g (- x)).
>> [...]
>> > 7. These recurse left-to-right. E.g., f{n - 1}(x) => f({n - 1})(x) =>
>> >    (f (- n 1))(x)  ((f (- n 1)) x)
>>
>> For consistency with the rule given in item 2, I suggest rewriting the
>> first intermediate step "f({n - 1})(x)" in item 7 as "(f {n - 1})(x)".
>
> Agree, done.
>
>> Also, since items 4 through 6 use the word "MUST", for consistency I
>> suggest writing "7. These MUST recurse left-to-right."
>
> Agree, done.
>
>> > 4. There MUST NOT be whitespace between e and the open paired character
>> >    for the above mappings to apply.
>>
>> This requirement seems poorly worded for reasons that I find difficult to
>> explain.  It has to do with "MUST NOT" being applied to a condition that
>> might or might not be true (whitespace between e and the open paired
>> character), rather than to an action that the implementation must not
>> take.
>>
>> I suggest rewriting it as something closer to: "The above mappings MUST
>> NOT be applied if whitespace characters are present between e and the
>> open
>> paired character."
>
> and later:
>> s/whitespace characters/one or more whitespace characters/
>> "The above mappings MUST NOT be applied if one or more whitespace
>> characters are present between e and the open paired character."
>
> Agree, done.
>
>> > Where datum comments are supported using #;, datum comments SHOULD
>> > comment the datum as defined above.
>>
>> You might consider referencing SRFI-62, which was the first specification
>> for these datum comments (later adopted by both R6RS and R7RS).
>
> Yes, I think we should mention all three.
>
>
> Alan Manuel Gloria:
>> I was reading through Guile-devel and found this gem by Mark H. Weaver:
>> http://www.mail-archive.com/guile-devel@xxxxxxx/msg10088.html
> ...
>> The explanation might look good in the design rationale.
>
> Agreed.  Fixed in my local copy.
>
> I'll try to post an update later today, if the hurricane lets me.
>
> --- David A. Wheeler
>
>