On Thu, Dec 15, 2011 at 9:13 AM, Gregory Crosswhite
gcrosswh...@gmail.comwrote:
To quote Ross Paterson's proposals:
instance Alternative [] where
...
some [] = []
some (x:xs) = repeat (repeat x)
many [] = [[]]
many (x:xs) = repeat (repeat x)
Isn't this instance
On 17/12/2011, at 3:35 PM, Matthew Farkas-Dyck wrote:
On 15/12/2011, Gregory Crosswhite gcrosswh...@gmail.com wrote:
1) Documentation really needs to be improved
2) some/many cannot be physically separated from Alternative, but there
*might* be an advantage to creating a subclass for them
On Sun, Dec 18, 2011 at 20:42, Richard O'Keefe o...@cs.otago.ac.nz wrote:
No. Not by a country mile.
It's better than non-existent.
It's better than misleading.
But it's not even on the same *continent* as adequate.
+1
--
brandon s allbery
On Dec 19, 2011, at 12:39 PM, Brandon Allbery wrote:
On Sun, Dec 18, 2011 at 20:42, Richard O'Keefe o...@cs.otago.ac.nz wrote:
No. Not by a country mile.
It's better than non-existent.
It's better than misleading.
But it's not even on the same *continent* as adequate.
+1
So what do
On 19/12/2011, at 3:44 PM, Gregory Crosswhite wrote:
So what do you all think about my own suggestion for the documentation?
It is an improvement.
Documentation for a library module needs to start by telling people what
it is for. For a particular function, someone needs to know very quickly
On Sun, Dec 18, 2011 at 6:44 PM, Gregory Crosswhite
gcrosswh...@gmail.comwrote:
On Dec 19, 2011, at 12:39 PM, Brandon Allbery wrote:
On Sun, Dec 18, 2011 at 20:42, Richard O'Keefe o...@cs.otago.ac.nz wrote:
No. Not by a country mile.
It's better than non-existent.
It's better than
On Dec 19, 2011, at 1:03 PM, Alexander Solla wrote:
The incidental comment is significantly more clear than an English
description.
That is only true for someone who has already seen a sentence like that one
before and so can immediately pick up what it is getting at. :-) In
particular,
On Dec 19, 2011, at 1:01 PM, Richard O'Keefe wrote:
On 19/12/2011, at 3:44 PM, Gregory Crosswhite wrote:
So what do you all think about my own suggestion for the documentation?
It is an improvement.
Documentation for a library module needs to start by telling people what
it is for.
On Dec 19, 2011, at 1:01 PM, Richard O'Keefe wrote:
Documentation for a library module needs to start by telling people what
it is for. For a particular function, someone needs to know very quickly
is this what I am looking for? is this the kind of thing I _should_ have
been looking for?
On 19/12/2011, at 5:46 PM, Gregory Crosswhite wrote:
[improved Monoid documentation]
I would go so far as to point out that mappend is a generalisation of
Data.List.sum, Data.List.product, Data.List.and, and Data.List.or,
where the initial value and combining rule are implied by the type.
On Dec 19, 2011, at 3:49 PM, Richard O'Keefe wrote:
On 19/12/2011, at 5:46 PM, Gregory Crosswhite wrote:
[improved Monoid documentation]
Thank you. :-)
I would go so far as to point out that mappend is a generalisation of
Data.List.sum, Data.List.product, Data.List.and, and Data.List.or,
On Dec 19, 2011, at 4:45 PM, Gregory Crosswhite wrote:
First, there needs to be lots of [STRUCTURE] that makes it easy for people to
skim through and pick out the specific information that they want to find out
about [...]
Grr! I have no idea why that word got dropped out, since it was
On 16/12/2011, Gregory Crosswhite gcrosswh...@gmail.com wrote:
On Dec 17, 2011, at 12:35 PM, Matthew Farkas-Dyck wrote:
(1) If we do (4), then the documentation ought to be adequate as-is.
I see your point that if we do (4) then some and many are no longer
problematic for Maybe and [], and
On 15/12/2011, Gregory Crosswhite gcrosswh...@gmail.com wrote:
1) Documentation really needs to be improved
2) some/many cannot be physically separated from Alternative, but there
*might* be an advantage to creating a subclass for them anyway purely for
the sake of conveying more information
On Dec 17, 2011, at 12:35 PM, Matthew Farkas-Dyck wrote:
(1) If we do (4), then the documentation ought to be adequate as-is.
I see your point that if we do (4) then some and many are no longer problematic
for Maybe and [], and thus we don't need warnings for those types. However,
Hey everyone!
First of all, it sounds like we all agree that the documentation for
Alternative needs to be improved; that alone would clear a lot of the
confusion up.
I think that a fairly convincing case has also been made that removing
many/some from the typeclass doesn't help too much
On Thu, Dec 15, 2011 at 9:13 PM, Gregory Crosswhite
gcrosswh...@gmail.com wrote:
First of all, it sounds like we all agree that the documentation for
Alternative needs to be improved; that alone would clear a lot of the
confusion up.
I wonder if fully documenting the Haskell base library is a
17 matches
Mail list logo
