Don't derive Data

[treeowl]

Currently, we derive a Data instance for Stream. This seems wrong, because it allows users to distinguish streams based on Effect layering. The way to stick with the current general approach is to work on unexposed streams. Another major option would be to proclaim that Stream is just a representation of something like FreeT, and make a Data instance emulating that. That might be going too far, though.

[andrewthad]

I don't even really know what people use `Data` for. I've only ever used the generic programming stuff from `GHC.Generics`. That being said, I'm slightly in favor of removing it (or hand-writing the instance as you suggest) since this library isn't supposed to let users observe its violation of the the `MonadTrans` laws.

…

On Fri, Sep 15, 2017 at 2:22 PM, David Feuer ***@***.***> wrote: Currently, we derive a Data instance for Stream. This seems wrong, because it allows users to distinguish streams based on Effect layering. The way to stick with the current general approach is to work on unexposed streams. Another major option would be to proclaim that Stream is just a representation of something like FreeT, and make a Data instance emulating that. That might be going too far, though. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#25>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFFeBHo95eOPw94qTJsX1gKWO3vmm6pHks5sisBvgaJpZM4PZVt8> .

-- -Andrew Thaddeus Martin

[chessai]

Something a normal user might use Data for: https://hackage.haskell.org/package/template-haskell-2.13.0.0/docs/Language-Haskell-TH-Syntax.html#v:liftData