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

Re: A few more minor tweaks

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