Hi Andrew,
On Wed, Jul 04, 2007 at 07:26:48PM +0100, Andrew Coppin wrote:
Writing documentation for libraries is one way in which ordinary
Haskell users can really contribute to the Haskell community. It’s not
hard to do (grab the Darcs repo, type away), and it’s widely appreciated.
| Fortunately, some kind soul has gone through and converted the
| documentation to haddock format:
| http://hackage.haskell.org/trac/ghc/ticket/1410
|
| So it'll all appear in the html docs in the next version. In the mean
| time one can look at the haddock comments in the source:
|
.
Simon
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brent Yorgey
Sent: 03 July 2007 22:09
To: Andrew Coppin
Cc: haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] Sparse documentation
It's also nice to have some brief comments in the API docs to say what
the heck a particular
On Wed, 2007-04-07 at 08:03 +0100, Simon Peyton-Jones wrote:
| Fortunately, some kind soul has gone through and converted the
| documentation to haddock format:
| http://hackage.haskell.org/trac/ghc/ticket/1410
|
| So it'll all appear in the html docs in the next version. In the mean
| time
Andrew Coppin wrote:
Essentially I want to run a parser on top of a parser, and I think maybe
this is the way to do it.
I doubt monad transformers are the answer.
I imagine you just want to one run parser over the result of the
previous, which is just function composition, modulo a sensible
Simon, if the less-talented among us (like me) want to contribute to
GHC's docs -- and especially documenting the libraries -- what's the
best way to go about this? I'm not too comfortable with the notion of
just going into GHC's guts and Haddocking the comments, contributing
patches willy-nilly
Simon Peyton-Jones wrote:
Writing documentation for libraries is one way in which ordinary
Haskell users can really contribute to the Haskell community. It’s not
hard to do (grab the Darcs repo, type away), and it’s widely appreciated.
People often don’t feel “qualified” do to this, but
Jules Bean wrote:
Andrew Coppin wrote:
Essentially I want to run a parser on top of a parser, and I think
maybe this is the way to do it.
I doubt monad transformers are the answer.
I imagine you just want to one run parser over the result of the
previous, which is just function composition,
Is there a reason why the documentation for virtually every module in
Control.Monad simply begins with a line that says
Inspired by some paper (http://www.ogi.edu/csee/~mpj/)
and then just shows you a bunch of type signatures, without telling you
*anything* about what the module is supposed
Is there a reason why the documentation for virtually every module in
Control.Monad simply begins with a line that says
Inspired by some paper (http://www.ogi.edu/csee/~mpj/)
It's probably because it was felt that the paper itself is better
documentation than anything that could be written
Is there a particular module you're having trouble with? Or just griping in
general? =)
How about STM? It would be nice if I didn't have to scan the paper each
time I do something with STM. Isn't that the point of having an API
reference?
-Brent
Tim Newsham
On Tue, 2007-07-03 at 15:11 -0400, Brent Yorgey wrote:
Is there a reason why the documentation for virtually every
module in
Control.Monad simply begins with a line that says
Inspired by some paper (http://www.ogi.edu/csee/~mpj/)
It's probably
recorded,
or fixed?-)
claus
- Original Message -
From: Andrew Coppin [EMAIL PROTECTED]
To: haskell-cafe@haskell.org
Sent: Tuesday, July 03, 2007 7:38 PM
Subject: [Haskell-cafe] Sparse documentation
Is there a reason why the documentation for virtually every module in
Control.Monad
On Tue, 3 Jul 2007 09:23:02 -1000 (HST)
Tim Newsham [EMAIL PROTECTED] wrote:
How about STM? It would be nice if I didn't have to scan the paper
each time I do something with STM. Isn't that the point of having an
API reference?
-Brent
Tim Newsham
http://www.thenewsh.com/~newsham/
Tim Newsham wrote:
Is there a particular module you're having trouble with? Or just
griping in
general? =)
How about STM? It would be nice if I didn't have to scan the paper
each time I do something with STM. Isn't that the point of having an
API reference?
Similar remarks hold for
Brent Yorgey wrote:
Is there a reason why the documentation for virtually every module in
Control.Monad simply begins with a line that says
Inspired by some paper (http://www.ogi.edu/csee/~mpj/
http://www.ogi.edu/csee/%7Empj/)
It's probably because it was felt that the
It's also nice to have some brief comments in the API docs to say what
the heck a particular module is even *for*, and provide enough info on
the stuff in that module that you can quickly dip into it when you can't
remember the name of something...
I certainly don't disagree with you! I was
It's also nice to have some brief comments in the API docs to say what the
heck a particular module is even *for*, and provide enough info on the
stuff in that module that you can quickly dip into it when you can't
remember the name of something...
agreed.
for me, the perldocs for most
18 matches
Mail list logo