Can hackage documentation mismatch with actual code?

#1

Think I was just bitten by the case.

Was thinking that a function is reasonably typed looking at hackage, but it ends up in error in actual code. Turns out the type in code wasn’t what expect.

Is it possible that hackage documentation is out of sync?

#3

To be more specific, it was difference between
getClass :: a -> Maybe Text (hackage documentation)
and
getClass :: a -> Text (real code)

I think the rust documentation one is a bit orthogonal, as this one is literal type mismatch.

#4

Why don’t you just link us to the documentation page in question? Then we can easily work out if it’s out of sync.

(The answer to your question is, in principle, yes, because anyone can upload anything as the purported documentation of a package, but I suspect it’s more helpful to actually look at the one that caused you problems. An alternative cause is that you were looking at the Haddock page for a different version of the package than you were actually using.)

1 Like
#5

Oh. Now this explains it.
It is gi-gio-2.0.29's hackage documentation and actual code has signature mismatch · Issue #383 · haskell-gi/haskell-gi · GitHub btw.
I thought the documentation is automatically compiled…

#6

I believe the haskell-gi family of libraries are all (mostly?) automatically generated packages from the gobject-inspection files of the associated Gnome (GTK) system libraries. The types of the functions within can depend on what versions of the the system libraries you have installed.

This was something I found somewhat confusing when I started working with haskell-gi.

You sometimes see people creating CPP macros/flags in their Setup.hs that they can use in their Haskell code to be able to support multiple system library versions. For example:

1 Like
#7

Thank you! This solved the mystery. I guess it is time to blame the ubuntu’s package not being updated.

1 Like