haddocks list data family instances that arent exported!

[cartazio]

my minimal repro is this the resulting haddocks list ALLLL known Unboxed Vector/MVector data family instances and type class instances! I'm not sure how much is at fault on the haddock or GHC side respectively.

{-# LANGUAGE TypeFamilies #-}
module M1(MyUnit(..),UV.Vector(V_MU),UV.MVector(MV_MU)) where

import Data.Vector.Unboxed as UV

--type instance VG.Mutable MyV = MyMV

data MyUnit = MU

newtype instance UV.MVector s MyUnit  = MV_MU ()
newtype instance UV.Vector    MyUnit = V_MU ()

[cartazio]

if I import this module

module M2 where

import M1

a :: Vector Int
a = V_Int (error "impossible")
--- V_Int not in scope

b :: Vector Int 
b = undefined --- this works 

V_Int wont be in scope, but Vector Int will be well defined

[cartazio]

crazilly, if I change it to be

module M2 where

import M1

--a :: Vector Int
--a = V_Int (error "impossible")
--- V_Int not in scope

b :: Vector Int
b = undefined --- this works

data Foo = F

c :: Vector Foo
c = undefined

the c :: Vector Foo type checks fine

[Fuuzetsu]

So it seems to me that instances are all exported, just the way to construct some of the values aren't which would be consistent with type classes &c and therefore not a bug. Am I wrong?

[cartazio]

I think you're right. I'm experimenting with an approach so I can get the same ROI as if i exported the constructors, but not drag in the whole massive haddocks.

[nikita-volkov]

I'm suffering from the same issue here. None of the constructors are actually exported by the API, but Haddock deflowers the docs:

http://hackage.haskell.org/package/hasql-postgres-0.5.1/docs/Hasql-Postgres.html

It's easy to prove that it's a Haddock bug. Importing that module and trying to use one of those constructors results in:

Not in scope: data constructor ‘H.StatementArgument’

[Fuuzetsu]

That does not seem like a ‘proof’: the instance still leaks out (just like with type classes) and Haddock even knows exactly where to find StatementArgument.

I'd like to point out that Haddock only sees what GHC tells it, no more: we do no guessing or active search for instances/constructors/whatever ourselves and if something leaks out then it's either GHC API fault for telling us about it OR Haddock's fault about not using the API correctly OR user seeing behaviour that they personally don't expect.

I believe @cartazio established on IRC that if you :i the family, the instances show up even though you might not be importing anything yourself. In this case I'm not sure what is expected that Haddock would do.

[nikita-volkov]

I think there's a misunderstanding. The Data Constructor is not exported. It is not usable when the module is imported. The :i does not list it. But nonetheless Haddock does generate docs for it.

Here's the output of :i:

λ>:i HB.StatementArgument 
class HB.Backend b where
  type role HB.StatementArgument nominal
  data family HB.StatementArgument b
  ...
    -- Defined in ‘Hasql.Backend’
data HB.StatementArgument Postgres
  -- Defined at library/Hasql/Postgres.hs:49:8

See? No data constructors.

So in the generated docs it should be:

data StatementArgument Postgres

instead of

data StatementArgument Postgres = StatementArgument Oid (Environment -> Maybe ByteString)

as it is now.

[Fuuzetsu]

OK, I will have a look at what GHC spits out when time allows (closer to end of the month at best unless I manage to squeeze this in somehow faster). I have a suspicion that either we won't be able to easily tell if the constructor is in scope or it will be an easy fix. Ideally we can get this in with GHC 7.10 but I'm swarmed so no promises.

If you want to contribute small, self-contained test-case and carefully note the expected and actual results so that we can include it in the test-suite, that'd be great help.

[cartazio]

It looks like theres a GHC ticket thats related to this https://ghc.haskell.org/trac/ghc/ticket/10027

[Kleidukos]

Any development on that front? cc @cartazio @Fuuzetsu

[Fuuzetsu]

I don't think so. Trying to push forward #897 is probably anyone's best bet but I have no idea to the status of the project currently, I'm not sure if there's really a maintainer.