Hi, I cannot find a similar ticket, so it seems that no one has filed this issue before. As a general comment, I think this issue is a good example that perhaps docstrings should go in the AST. In any case, I would ask someone with a trac account in Haddock to submit this ticket for me. I apologize for the inconvenience, but, for privacy concerns, I don't want an account in Haddock trac and it does not seem possible to submit a ticket without first creating one. Thanks, Jose On Fri, Aug 16, 2013 at 12:51:35AM +0300, Roman Cheplyaka wrote:

In any case, it shouldn't fail with a parse error, since this is valid Haskell.

Please file a ticket at http://trac.haskell.org/haddock (but first see if it hasn't been reported before).

Roman

* jabolopes@google.com [2013-08-15 15:24:23-0400]

...

Hi,

I am using

GHC: 6.12.1 Haddock: 2.6.0

and the following does not work with Haddock (GHC is fine!):

-- Main

-- | Blah blah blah (x, y, z) = (1, 2, 3)

$ haddock ... /tmp/Main.hs:2:0: parse error on input `('

Is this a bug? Or it's just not part of Haddock?

This seems like an interesting feature to document several definitions together, for example, error codes:

-- | Syscall error codes for blah... -- -- errA when blah -- ... (errA, errB, errC) = ...

Cheers, Jose

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On 16/08/13 08:16, Mateusz Kowalczyk wrote:

In the future, please try with more recent version of GHC.

This is no longer a parse error with HEAD or 7.6.3. Instead, given

-- | 'y' and 'x' are here (x, y) = (1, 2)

you get documentation generated for ‘x’ and Haddock doesn't seem to have any idea where to link ‘y’ (but it does know it's in scope &c). I think this behaviour is understandable considering that ‘x’ is the first ‘function’ after Haddock comments so the comment belongs to ’x’. If you want a different behaviour, please file an enhancement request against a recent version to have it considered.

I would like to add onto this that we can actually get the Haddock documentation generated for ‘y’ by exporting it in the module and then we can easily link to it, you're simply not getting the Haddock comment along.

I don't understand your concern over privacy in this case: you're getting a lot more exposure just posting on café than you ever would by posting directly on the low-traffic Haddock Trac. You're free to register with a temporary e-mail.

http://trac.haskell.org/haddock

Apologies for consecutive posts. -- Mateusz K.

On 16/08/13 11:08, Roman Cheplyaka wrote:

* Mateusz Kowalczyk [2013-08-16 08:16:35+0100]

...

In the future, please try with more recent version of GHC.

This is no longer a parse error with HEAD or 7.6.3.

Uhm, actually there is, with 7.6.3.

% cat haddock.hs -- Main

-- | Blah blah blah (x, y, z) = (1, 2, 3)

% haddock haddock.hs

haddock.hs:4:1: parse error on input `('

% haddock --version Haddock version 2.13.2, (c) Simon Marlow 2006 Ported to use the GHC API by David Waern 2006-2008

It's great that it's fixed in HEAD.

Roman

Strange. /tmp $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.6.3 /tmp $ cat Test.hs module Main (main, y, x) where -- | this is a main 123 function main :: IO () main = return () -- | Haddock likes 'y' and 'x', 'foobar' (x, y) = (1, 2) /tmp $ ghc Test.hs [1 of 1] Compiling Main ( Test.hs, Test.o ) Linking Test ... /tmp $ haddock --version Haddock version 2.13.2, (c) Simon Marlow 2006 Ported to use the GHC API by David Waern 2006-2008 /tmp $ haddock Test.hs --html Haddock coverage: Warning: Couldn't find .haddock for export Main.y 50% ( 2 / 4) in 'Main' Warning: Main: could not find link destinations for: GHC.Types.IO GHC.Integer.Type.Integer /tmp $ Well, it's a high possibility that my Haddock version isn't the stock one that comes with 7.6.3. In any case, I'm glad that you say it's fixed in HEAD. Thanks for checking. -- Mateusz K.