Show instance for UTCTime about time HOT 24 CLOSED

@jpvillaisaza thanks for the info.

I still think this is a problem. At the very least, haddocks and the code should somehow be made compatible.

from time.

Here's a similar (quite old) question: http://stackoverflow.com/questions/3223576/cannot-derive-a-show-instance-for-data-containing-utctime.

Basically, import Data.Time:

$ ghci
> import Data.Time (getCurrentTime)
> getCurrentTime >>= print
2014-11-24 20:31:07.360965 UTC

from time.

I have also run into this problem.

from time.

Orphan instances do not belong. Correcting documentation is not an acceptable consolation.

from time.

I'm of the opinion that orphan instances are a lot less harmful than some people suppose, particularly when the type (or the class) and the instance are all in the same package.

The orphan instance problem happens when there is more than one instance for a given class and type. This is much more likely to happen when it isn't clear which instance is the "proper" one, or if the authors of the instances aren't aware of each other's code. This seems unlikely in this case: clearly the instance defined in the package is the proper one.

And the only actual effect of the problem is that Haskell will use whichever instance is in scope, or reject the program if they both are. This is not particularly bad behaviour. I would describe it as, at worst, slightly awkward.

from time.

@AshleyYakeley can you please respond to the original problem, and see if you don't think that's a problem any more?

Just to clarify: UTCTime reports to have a Show instance available in the documentation of Data.Time.Clock, but loading that module into ghci doesn't bring the claimed instance into scope.

from time.

Oh, I had missed the previous documentation update. I can live with this. Though it is a shame the problem wasn't "properly" solved by either bringing the instance into scope or not listing the instance in the documentation at all.

from time.

The package author does not have a choice to omit it from documentation, as far as I know. That is determined by Haddock.

from time.

@tomjaguarpaw so maybe this can be regarded as a bug of Haddock. It probably should only list the instances that are in scope for a given module.

from time.

@ozgurakgun the problem is though, if Haddock showed only the locally visible instances for modules which expose a data-type, you'd have a hard time figuring out which orphan instances exist at all

from time.

Right, it's two separate things: "instances defined in this module" and "instances for this type or class". The former is part of the contents of the module, the latter is more "see also". But I think Haddock only shows the latter.

from time.

Current Haskell culture really discourages orphan instances. So that makes this behaviour highly surprising even with the documentation.

Would you be open to a patch if someone else jumped in to help?

from time.

No.

from time.

Why?

from time.

@gbaz, orphan instances are a lot less harmful than some people suppose, particularly when the type (or the class) and the instance are in the same package.

The orphan instance problem happens when there is more than one instance for a given class and type. This is much more likely to happen when it isn't clear which instance is the "proper" one, or if the authors of the instances aren't aware of each other's code. This seems unlikely in this case: clearly the instance defined in the package is the proper one.

And the only actual effect of the problem is that Haskell will use whichever instance is in scope, or reject the program if they both are. This is not particularly bad behaviour. I would describe it as, at worst, slightly awkward.

from time.

Ok. I understand the confusion. You are responding with a defense of this orphan as not bad because it will not lead to duplication of instances. There I completely agree!

However, what we have is a different problem -- one that leads to confusion in using the library, which is that it is possible to bring the datatype into scope without its attendant instances. This behavior is confusing to end-users, as the ticket demonstrates (and I've run into the same thing in the past, as I know others have). I'm not supporting this change because of a moral position on orphans internal to a library -- I'm supporting it because it is a far nicer experience for end-users to have instances for things like Show arrive along with attendant datatypes instead of them needing to import said instances from elsewhere.

If, "behind the scenes" there were an internal module that had the type, and another with instances on the type, but in the public interface, pulling in the module with the type also pulled in the instances, for example, I would find that fine too.

Does that help clear up the concern?

from time.

@gbaz 👍

from time.

@gbaz +1

from time.

@gbaz 👍

from time.

@gbaz 👍

from time.

@gbaz 👍

from time.

I agree with Gershom that being able to get the data type and not the instance through the public API of the package without going through a module that is clearly flagged as "evil and internal" is confusing.

It isn't like the user can just make local decisions on the right instance here, unless they happen to also know that they aren't using any other code anywhere that also happens to make that decision one way or another on the choice of instance.

This isn't really a locally decidable affair.

from time.

@gbaz 👍

from time.

@gbaz Is your idea of a behind the scenes solution (see #7 (comment)) similar to what the Data.Time module does? It exports everything, so if you import that one you get both the getCurrentTime function and Show instance for UTCTime for example. I don't know if that's a complete solution (you can install import Data.Time.Clock and still not get the instance, it only works if you import Data.Time or both Data.Time.Clock and Data.Time.Format), but that module could help with your idea.

I'm also not sure if this issue should be closed. Now there's a new issue with the problem (#25).

from time.