[haddock] #69: Errors with class members

haddock haddock at projects.haskell.org
Mon Jan 26 09:30:32 EST 2009

#69: Errors with class members
Reporter:  NeilMitchell  |        Owner:       
    Type:  defect        |       Status:  new  
Priority:  major         |    Milestone:  2.4.2
 Version:  2.5.0         |   Resolution:       
Keywords:                |  
Comment (by simonmar):

 Replying to [comment:9 simonmar]:
 > Replying to [comment:8 waern]:
 > > I agree with this, but in this particular case, the record fields are
 not duplicated in the export list,  because the class is exported
 abstractly. When exporting a class abstractly, and its fields separately,
 the fields are added to the class definition in the documentation, *and*
 shown at the top level.
 > Oh, in that case it's a bug then.  Sorry for missing the point!

 (simon thinks a bit more...) So I think the point illustrated by `Bug6.hs`
 is that if you export a record field separately from the record
 constructor, clients can still use the field in pattern matching and so
 on.  Hence we should make it visible in the documentation that this is a
 record field and not just a function.  Similarly for class methods: if the
 methods are exported separately from the class, this might enable clients
 to make instances of the class, if enough of the methods are visible.

 So now I think that Haddock should emit a warning in this case.  Perhaps
 GHC itself should emit a warning too.  The user should change the export
 list to read
 module M (B(b,B), ...)
 because that is semantically equivalent to
 module M (B(B), b, ...)
 but is better for documentation.

 Given the second version, whether Haddock generates two copies of the
 documentation for `b` or just one, I don't really mind, as long as it
 emits a warning to say what it is doing.

Ticket URL: <http://trac.haskell.org/haddock/ticket/69#comment:10>
haddock <http://www.haskell.org/haddock>
Haddock, The Haskell Documentation Tool

More information about the Haddock mailing list