Simon Peyton-Jones wrote:
> | (1) In the first section, in:
> |
> | instance (cx, cx') => Ci (T u1 ... uk) where { d }
> |
> | the use of "(cs, cs')" is a bit loose (that is, suggestive rather than
> | precise syntax). One can't (according to the report, though GHC seems
> to
> | allow it) have nested parentheses in a context, which would occur if
> cx
> | included parentheses.
>
> True --- but I think it's too late to improve this. I don't think it's
> misleading enough to matter.
Agreed.
> | (2) In section D.1, in:
> |
> | For example, False < _|_ is _|_, even though False is the first
> | constructor of the Bool type.
> |
> | change the operator from "<" to "<=". There is no reason to expect
> (False <
> | _|_) to be True.
>
> Good idea.
>
> | (3) Section D.4 gives the expected rule:
> |
> | head (readsPrec d (showsPrec d x "")) == (x,"")
> |
> | Why should this not be:
> |
> | readsPrec d (showsPrec d x "") == [(x,"")]
>
> I can't think why not, unless there is a shorter valid parse, which I
> suppose is conceivable. I'd rather not change this.
In fact, neither rule above is true for the example given in section D.5.
To see this, run the following program:
infix 5 :^:
data Tree a = Leaf a | Tree a :^: Tree a deriving (Eq, Ord, Read, Show)
main = mapM_ trial [0..10]
where trial d = print (readsPrec d (showsPrec d x "") :: [(Tree Int,
String)])
x = Leaf 1 :^: Leaf 2
Perhaps we want:
readsPrec should be able to parse the string produced by showsPrec, and
should deliver the value that showsPrec started with. That is, the list
result of
readsPrec d (showsPrec d x "")
should contain exactly one pair whose second element is "", and the first
element of that pair should be equivalent to x.
> | (4) I don't understand this paragraph in section D.4:
> |
> | readsPrec will parse any valid representation of the standard
> types
> | apart from lists, for which only the bracketed form [...] is accepted.
> See
> | Appendix A for full details.
> |
> | The statement seems to say that ((readsPrec 5 (show
> | "abc"))::[([Char],String)]) is invalid, but that can't be what it
> means to
> | say.
>
> Sigh. You are right. For strings, only "foo" is acceptable. (GHC
> accepts the ['f','o','o'] form too, but the Report does not. So I guess
> the wording should be:
>
> "readsPrec will parse any valid representation of the standard types
> apart from strings, for which only quoted strings are accepted, and
> other lists, for which only the bracketed form [...] is accepted. "
That's better.
> | (5) The next paragraph of section D.4 says:
> |
> | Spaces and parentheses are only added where needed, ignoring
> | associativity.
> |
> | The phrase "only where needed" suggests that (show (1 :$ 2 :$ NT))
> should
> | produce the string "1:$(2:$NT)" (no spaces) rather than the string "1
> :$ (2
> | :$ NT)", as claimed later in the section (and borne out by GHC). It
> needs
> | to be stated that an infix operator is preceded and followed by a
> space.
>
> Maybe I should remove "spaces and"; this is really only about parens.
That sounds good.
> | (6) In the bullet that begins "The derived Read instance allows",
> change
> | "parenthese" to "parentheses".
>
> Thanks
>
> Simon
-- Dean
_______________________________________________
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
