
I am trying to use Haddock for the first time on windows for a reasonably large project. I must be completely clueless because I seem to generate a lot of parse errors that have no reasonable explanation. In some cases it seems like Haddock is white space sensitive requiring the same indentation as my source code. If so, this is not clearly documented. However consider this example: in my matrix library I have this code snippet: ... -- | class instance Rmatrix, real only matrices instance Matrix Rmatrix where -- | tells us if its a submatrix (better to use pattern matching) issub x = case x of Rindx n -> False Rsubindx n -> True ... This generates a parse error on the line -- | class instance Rmatrix, real only matrices at the first s in class. Removing the | from the comment generates a parse error on the instance declaration even though there are no haddock comments that apply to it! The code prior to this looks something like... -- | copy one matrix into another copy :: m -> m -> m copy a b = mio $ do ka <- pushsub a ... and is part of the class declaration itself. I'm not sure why an auto-documentation tool shouldn't be a bit more forgiving vis a vis it's syntax. Maybe flag errors as warnings but keep on going. I run haddock from the command prompt via the command haddock.exe -o docs -v -h matrix.hs

Matthew Bromberg wrote:
...
I'm not sure why an auto-documentation tool shouldn't be a bit more forgiving vis a vis it's syntax. Maybe flag errors as warnings but keep on going. ...
I can't help you about the haddock thing but, in my experience, if you forgive that kind of mistakes, many users will write documentation with lots of warnings and say "ok, these docs ain't right but, it works for me". I guess this is mostly what has happened to HTML, you can find lots and lots of documents that "work" (well, depending on the browser you are using), but they are obviously wrong. Maybe the solution to this kind of problems is haddock to give more information about the parse error, like: "Found token <A> when expecting one of <B>,<C> or <D>", so at least you know what you should have written instead.

Ivan Perez-4 wrote:
Matthew Bromberg wrote:
I can't help you about the haddock thing but, in my experience, if you forgive that kind of mistakes, many users will write documentation with lots of warnings and say "ok, these docs ain't right but, it works for me". I guess this is mostly what has happened to HTML, you can find lots and lots of documents that "work" (well, depending on the browser you are using), but they are obviously wrong.
Maybe the solution to this kind of problems is haddock to give more information about the parse error, like: "Found token A when expecting one of B or D", so at least you know what you should have written instead. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
I understand your point, but this is documentation, not mission critical code. I am fortunate that I even have time to try to fix this right now. Had I seen this last week I would have just given up in frustration. Here is another arcane example -- | compute cos (theta / 2) assuming the branch [-pi, pi] halfcos :: Double -> Double halfcos cs = sqrt $ (cs + 1)/2 This produces a parse error parse error in doc string: [haddock.exe: reading EOF! on the h of the halfcos :: Double -> Double line Don't get me wrong, I am appreciative of the fact that this tool exists, I'm just having trouble using it properly. Also I'm the kind of person that views warnings when compiling my source code as errors. Thus I wouldn't accept unproperly formatted html. For code documentation, however, I can't get that worried about it. -- View this message in context: http://www.nabble.com/Haddock-Parse-Errors-tf2396951.html#a6684878 Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

SevenThunders wrote:
-- | compute cos (theta / 2) assuming the branch [-pi, pi] halfcos :: Double -> Double halfcos cs = sqrt $ (cs + 1)/2
This produces a parse error parse error in doc string: [haddock.exe: reading EOF! on the h of the halfcos :: Double -> Double line
For the benefit of others who might encounter similar issues. This error was apparently generated by the existence of / in (theta / 2). The fix is to replace it with (theta \/ 2). -- View this message in context: http://www.nabble.com/Haddock-Parse-Errors-tf2396951.html#a6685168 Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

SevenThunders wrote:
I am trying to use Haddock for the first time on windows for a reasonably large project.
After playing around with this some, it appears that some of my parse errors are occuring on functions that have no explicit type declarations. E.g. things like -- | tells us if its a submatrix (better to use pattern matching) issub x = case x of Rindx n -> False Rsubindx n -> True Some of these functions are really annoying to write type declarations for. Maybe I'll get ghci to do it for me and use cut and paste :) I thought Haddock was just supposed to ignore these cases! The bottom line is that I just don't understand why I get parse errors in most cases. -- View this message in context: http://www.nabble.com/Haddock-Parse-Errors-tf2396951.html#a6684107 Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

David House wrote:
On 06/10/06, SevenThunders
wrote: Some of these functions are really annoying to write type declarations for. Maybe I'll get ghci to do it for me and use cut and paste :)
Try using type synonyms to bring the beasts to order.
-- -David House, dmhouse@gmail.com _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Yeah that's actually a cool idea. I notice ghci and haddock reusing my defined type synonyms. I'll definately use that more often thanks. -- View this message in context: http://www.nabble.com/Haddock-Parse-Errors-tf2396951.html#a6685190 Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
participants (4)
-
David House
-
Ivan Perez
-
Matthew Bromberg
-
SevenThunders