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 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
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 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 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
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
particula
On Sun, Dec 18, 2011 at 6:44 PM, Gregory Crosswhite
wrote:
>
> On Dec 19, 2011, at 12:39 PM, Brandon Allbery wrote:
>
> On Sun, Dec 18, 2011 at 20:42, Richard O'Keefe wrote:
>
>> No. Not by a country mile.
>> It's better than "non-existent".
>> It's better than "misleading".
>> But it's not even
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 Dec 19, 2011, at 12:39 PM, Brandon Allbery wrote:
> On Sun, Dec 18, 2011 at 20:42, Richard O'Keefe 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 you all t
On Sun, Dec 18, 2011 at 20:42, Richard O'Keefe 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 allber...@gmail.com
On 17/12/2011, at 3:35 PM, Matthew Farkas-Dyck wrote:
> On 15/12/2011, Gregory Crosswhite 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
On Thu, Dec 15, 2011 at 9:13 AM, Gregory Crosswhite
wrote:
> 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 conflating the ZipLis
On 16/12/2011, Gregory Crosswhite 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 thus we don't
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,
nonethele
On 15/12/2011, Gregory Crosswhite 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 about a type to use
On Thu, Dec 15, 2011 at 9:13 PM, Gregory Crosswhite
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 valid
SoC projec
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 sinc
17 matches
Mail list logo
