Herbert thinks that the patch is incomplete, although 90% done. It'll need to be finished in the next 6 days, including coordination with the transformers package, if it's to get into GHC 8.0.
Ryan, Ross: how much do you care? Do you want to make it happen?
I'm preoccupied with other tickets that I absolutely want to make it in before the 8.0 release, so I doubt I'll be able to get this one in time (especially since transformers-related changes require several rounds of back-and-forth between Ross, someone with GHC push access, and myself).
Ross: I would like to see this change get into GHC 8.0, time permitting.
There's one thing that bothers me about the most recent changes to transformers, however. After introducingShow1/Show2/et al, you changed the Show instances to use them. For instance, the Show instance for Backwardswas:
The result is that the output of show changes. Before, the output of show (Backwards "hello") would be "Backwards \"hello\"", but with the latest changes, it's "Backwards ['h','e','l','l','o']"! This is because the Show1 [] instance has to be parametric over its argument, so it can't tell that Char has a special Show instance that causes it to be shown differently.
I feel like we should revert all the Eq/Ord/Read/Show instance in transformers back to the way they were (and keep the Show1/Show2/etc. instances separate) to prevent subtle changes like this. Do you agree?
Ryan: I'm really very negative on the idea of reverting to the old approach.
We rather deliberately changed them in HEAD months ago to make it so that they can be used in more situations without requiring the Functor constraint a few months back, the old approach had rendered these classes useless for a lot of real world situations around GADTs and the like, in a way that simultaneously made implementations inefficient and less often applicable.
The old transformers approach winds up requiring
instance(Functorf,Eq1f,Eq1g)=>Eq1(Composefg)
while the current approach lets you use
instance(Eq1f,Eq1g)=>Eq1(Composefg)
and the code works in one pass regardless of whether or not f and g are known.
The price of admission is a manual implementation. The current compromise Ross has implemented gets a design that is readily implemented and implementable for a wide arrange of things.
Now, we could modify the way we pass in the "manual dictionary" version of 'Show/Read' to allow the showList/readList trick to work. It'd admittedly make the classes harder to implement and use. I could get behind an alternative API that passed in more stuff to readsPrecWith and showsPrecWith, or one that added a second combinator so that most people didn't have to deal with the noise.
I'd be okay with either proceeding with the status quo, or even more comfortable proceeding with a fix that modifies the methods in the Show1 and Read1 classes to pass more information, but it'd take a lot of convincing to bring me around to the old version in transformers, especially when we very consciously changed to get away from it!
Ryan: I'm really very negative on the idea of reverting to the old approach.
We rather deliberately changed them in HEAD months ago to make it so that they can be used in more situations without requiring the Functor constraint a few months back, the old approach had rendered these classes useless for a lot of real world situations around GADTs and the like, in a way that simultaneously made implementations inefficient and less often applicable.
The old transformers approach winds up requiring
instance(Functorf,Eq1f,Eq1g)=>Eq1(Composefg)
while the current approach lets you use
instance(Eq1f,Eq1g)=>Eq1(Composefg)
and the code works in one pass regardless of whether or not f and g are known.
The price of admission is a manual implementation. The current compromise Ross has implemented gets a design that is readily implemented and implementable for a wide arrange of things.
Now, we could modify the way we pass in the "manual dictionary" version of 'Show/Read' to allow the showList/readList trick to work. It'd admittedly make the classes harder to implement and use. I could get behind an alternative API that passed in more stuff to readsPrecWith and showsPrecWith, or one that added a second combinator so that most people didn't have to deal with the noise.
I'd be okay with either proceeding with the status quo, or even more comfortable proceeding with a fix that modifies the methods in the Show1 and Read1 classes to pass more information, but it'd take a lot of convincing to bring me around to the old version in transformers, especially when we very consciously changed to get away from it!
Yes, I'd come to the same conclusion, and have already made the necessary changes for Show1, and am now working through Read1. Note that the version before the changes also gave the wrong output on show (Compose (Just "abc")).
I've made a patch for splitting Data.Functor.Const into its own module, which is more or less orthogonal to migrating the functors from transformers into base.
There may be time to make this in for GHC 8.0 after all. I've prepared a patch for transformers which does the appropriate legacy711 migration of the Data.Functor.* modules, and backports Typeable/Data/Generic/Generic1 instances that will be introduced in base.
Note that there are some bad interactions between derived classes and PolyKinds, so I had to employ a few tricks to get the backported instances to work on old versions of GHC. Nevertheless, I tested my changes against every major version of GHC from 7.0–7.10, so this shouldn't break anything.