Re: Proposal: Add conspicuously missing Functor instances for tuples
Edward Kmett outlines his reasons why he finds instances for (,) useful here: https://www.reddit.com/r/haskell/comments/3pfg7x/either_and_in_haskell_are_n... Speaking for myself, I find the Traversable instance for (,) incredibly useful. It's quite nice to build up a list of results alongside a state (i.e, (state, [result]) ), and then traverse over each of the results such that the new results each have their own copy of the state (i.e., [(state, result)] ). That kind of patterns arises quite often in lensy code, and the Traversable instance for (,) is perfect for the job. Right now, if you want to have two different states, you have to employ a kludge (something like ((state1, state2), [result]) ) to get around the fact that there's no Traversable instance for (,,), (,,,), etc. Ryan S.
On Mon, 18 Jan 2016, Ryan Scott wrote:
Edward Kmett outlines his reasons why he finds instances for (,) useful here: https://www.reddit.com/r/haskell/comments/3pfg7x/either_and_in_haskell_are_n...
Speaking for myself, I find the Traversable instance for (,) incredibly useful. It's quite nice to build up a list of results alongside a state (i.e, (state, [result]) ), and then traverse over each of the results such that the new results each have their own copy of the state (i.e., [(state, result)] ). That kind of patterns arises quite often in lensy code, and the Traversable instance for (,) is perfect for the job.
Sounds like a nice application of the Writer monad, doesn't it? "Writer" would be much more explicit about what you want to achieve.
WriterT (and Writer) don't quite capture what I need. With WriterT, you have to tack on that extra m type parameter, and when you just specialize it to Identity, it only serves as an extra hoop to jump through to dig out the state. The prescence of the m type parameter also prevents me from easily modifying the state with a Bifunctor instance, whereas tuples have no such obstacle. It's a minor difference, but an important one when I decide which data structure to reach for. Ryan S.
On Mon, 18 Jan 2016, Ryan Scott wrote:
WriterT (and Writer) don't quite capture what I need. With WriterT, you have to tack on that extra m type parameter, and when you just specialize it to Identity, it only serves as an extra hoop to jump through to dig out the state. The prescence of the m type parameter also prevents me from easily modifying the state with a Bifunctor instance, whereas tuples have no such obstacle.
Is it important to achieve this with Bifunctor functions? You could write a state changing function, or add it to 'transformers', or define your own Writer as an independent type like it was in mtl initially.
It's a minor difference, but an important one when I decide which data structure to reach for.
Sure, but if you want a certain behaviour then a custom type is better than putting so much overloading to a standard (tuple) type, isn't it?
Is it important to achieve this with Bifunctor functions? You could write a state changing function, or add it to 'transformers', or define your own Writer as an independent type like it was in mtl initially.
For my use case, where I'm writing highly polymorphic code that needs to be able to work over several datatypes with two type parameters, using Bifunctor is quite less cumbersome than manually crafting individual functions tailored to each individual data structure. And while I certainly could define my own replacements for every single tuple type, it feels a bit silly doing so when the perfect datatypes are sitting right in front of me.
Sure, but if you want a certain behaviour then a custom type is better than putting so much overloading to a standard (tuple) type, isn't it?
The phrase "custom behavior" is a bit confusing to me, since there's
literally only one law-abiding Functor and Traversable instance for
any tuple type (and the Foldable implementation falls out from that).
These instances aren't custom behavior, they're the only behavior they
can have in this context.
And I certainly don't view tuple instances as being "overloaded". IMO,
their instances are quite well though-out consequences of their
structure. When you're parametrically polymorphic in the last type
parameter of a tuple, the operations you can perform on it are what
the Functor and Traversable instances so nicely give you.
Ryan S.
On Mon, Jan 18, 2016 at 5:10 PM, Henning Thielemann
On Mon, 18 Jan 2016, Ryan Scott wrote:
WriterT (and Writer) don't quite capture what I need. With WriterT, you have to tack on that extra m type parameter, and when you just specialize it to Identity, it only serves as an extra hoop to jump through to dig out the state. The prescence of the m type parameter also prevents me from easily modifying the state with a Bifunctor instance, whereas tuples have no such obstacle.
Is it important to achieve this with Bifunctor functions? You could write a state changing function, or add it to 'transformers', or define your own Writer as an independent type like it was in mtl initially.
It's a minor difference, but an important one when I decide which data structure to reach for.
Sure, but if you want a certain behaviour then a custom type is better than putting so much overloading to a standard (tuple) type, isn't it?
participants (2)
-
Henning Thielemann -
Ryan Scott