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

Re: A few more minor tweaks

This page is part of the web mail archives of SRFI 105 from before July 7th, 2015. The new archives for SRFI 105 contain all messages, not just those from before July 7th, 2015.



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