It's also interesting, though, to distinguish between two questions.  You are asking whether the Foldable superclass *costs* anything.  Others are asking whether it *adds* anything.

It seems likely, as you say, that the Foldable superclass doesn't cost us any possible Traversable instances.  You can probably demonstrate this by implementing foldMap in terms of traverse and some Applicative that lets you accumulate state.  (ST?  That would definitely work, but feels like driving in a nail with a sledgehammer.)  But the superclass does force Foldable on tuples, which has cost quite a bit in the long run!

So what is on the benefits side of the balance?  I'm very interested in this.  Possible answers that I see are.  If a substantial number of uses of Traversable also require Foldable, then it makes them more concise.  But I am not at all sure that's the case.

One interesting case here is mapM versus mapM_.  The former requires Traversable, but the latter is implementable from just Foldable.  It would be a shame if you could use mapM with some types, but not mapM_.

On Wed, May 3, 2017 at 4:56 AM, MarLinn <monkleyon@gmail.com> wrote:

It's a nice challenge to come up with datatypes that could be Traversable but not Foldable.

First of all, you can think of Traversable as an extension of Functor. Instead of only mapping over the structure with a pure function, you can now also map over it with a "functorial function" (a -> f b) (I don't know of a better name, so I'm inventing one.) What that means is to have a Traversable structure, you need to have the ability to touch every element. If you can touch every element, why would you not be able to feed them all into a folding function?

Only a few possible anwers come to mind for me:

  1. There might be no obvious ordering. But in practice, you just invent one.
  2. The structure might be infinite, so folding would never succeed. But laziness ftw.
  3. Generalizing the previous answer, the structure might be computed ad-hoc and contain fixed points. That alone might not suffice, but it sounds like a more interesting starting point.
  4. Generalizing a bit differently, the structure might be computed ad-hoc… because it's IO. IO surely can't be Foldable. But could it be Traversable? Well… no actually, because order is important.
So can you come up with a structure that is computed ad-hoc, that contains fixed points, and where ordering is unimportant? Good luck.

Cheers.



On 2017-05-03 11:56, Jonathon Delgado wrote:
OK, I understand why Traversable is useful here - thank you Chris and Dmitry!

The next question is why Traversable requires Foldable. I looked at the source, and couldn't see where Foldable is being used, other than as a constraint on Traversable. To put the question differently, what would fail to compile if this constraint was removed?



From: Dmitry Olshansky <olshanskydr@gmail.com>
Sent: 03 May 2017 09:53
To: Jonathon Delgado
Cc: haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] Foldable for (,)
  




With fmap you can only change all values in some "container".

 With Foldable you can "fold" it, i.e. calculate some "scalar" result.

 With Traversable you can "change order of two containers":

sequenceA [[1,2,3],[4,5]]

[[1,4],[1,5],[2,4],[2,5],[3,4],[3,5]]

sequenceA ("test",[2,3,4])

[("test",2),("test",3),("test",4)]

sequenceA ("test",([1,2,3],[4,5,6]))

([1,2,3],("test",[4,5,6]))





2017-05-03 12:12 GMT+03:00 Jonathon Delgado  <voldermort@hotmail.com>:
 Why do you want to traverse a tuple instead of fmap? i.e. what can you do with Foldable/Traversable for (,) that you can't do with Functor?

My background, as you can probably guess, is beginner.


From: Haskell-Cafe <haskell-cafe-bounces@haskell.org> on behalf of Chris Smith <cdsmith@gmail.com>
Sent: 03 May 2017 08:51
To: Tony Morris
Cc: haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] Foldable for (,)
 



Replying to myself, I suppose one good answer is that whether or not you care about Foldable instances for tuples, you might care about Traversable instances, and those require Foldable as a superclass.


For example, one possible specialization of `traverse` is:


    traverse :: (a -> IO b) -> (SideValue, a) -> IO (SideValue, b)


Jonathon, I don't know how much background you're coming from, so I'd be happy to explain that in more detail if you need it.


On Wed, May 3, 2017 at 1:44 AM, Chris Smith  <cdsmith@gmail.com> wrote:

I'm also interested in Jonathon's question, so let me try to bring things back to the question.  Everyone agrees that there's only one reasonable way to define this instance if it exists.  But the question is: why is it defined at all?


That's an easy question to answer for Functor, Applicative, and Monad.  But I am having trouble giving a simple or accessible answer for Foldable.  Do you know one?




On Wed, May 3, 2017 at 1:32 AM, Tony Morris  <tonymorris@gmail.com> wrote:
 It's Foldable for ((,) a).

It is not Foldable for any of these things:

* (,)
* tuples
* pairs

In fact, to talk about a Foldable for (,) or "tuples" is itself a kind
error. There is no good English name for the type constructor ((,) a)
which I suspect, along with being unfamiliar with utilising the
practical purpose of types (and types of types) is the root cause of all
the confusion in this discussion.

Ask yourself what the length of this value is:

[[1,2,3], [4,5,6]]

Is it 6? What about this one:

[(1, 'a'), (undefined, 77)]

Is it 4? No, obviously not, which we can determine by:

:kind Foldable :: (* -> *) -> Constraint
:kind [] :: * -> *

Therefore, there is no possible way that the Foldable instance for []
can inspect the elements (and determine that they are pairs in this
case). By this method, we conclude that the length of the value is 2. It
cannot be anything else, some assumptions about length itself put aside.

By this ubiquitous and very practical method of reasoning, the length of
any ((,) a) is not only one, but very obviously so.



On 03/05/17 17:21, Jonathon Delgado wrote:

I sent the following post to the Beginners list a couple of weeks ago (which failed to furnish an actual concrete example that answered the question). Upon request I'm reposting it to Café:

I've seen many threads, including the one going on now, about why we need to have:

length (2,3) = 1
product (2,3) = 3
sum (2,3) = 3
or (True,False) = False

but the justifications all go over my head. Is there a beginner-friendly explanation for why such seemingly unintuitive operations should be allowed by default?
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
   http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.


_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.



_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.   
     
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.


_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.