
I actually think the terminology may be the issue here: it's not tough to
think of cases where one might need to use (sum . fmap (const 1) ::
(Functor t, Foldable t) => t a -> Int), and it's also not tough to think of
cases where the term "length" doesn't fit everyone's expectation for what
that function does. On the other hand, there isn't really any other
Foldable-based implementation of 'length' that you can write.
On Mon, Apr 24, 2017 at 8:34 AM,
El 24 abr 2017, a las 03:20, David Thomas
escribió: One thing that's been missed in this discussion is that constraints can propagate.
Of course no one is wanting to pass something they know is a tuple into a function they know is length. But a function that expects something Foldable might want to know length or sum, and it might be reasonable to call that function on a tuple.
Do you have a real-world example of a case where that's useful, and difficult to achieve in another (non-Foldable) way?
Genuinely asking, so that when we talk about what's gained/lost we have something concrete to talk about.
Tom
Tony Morris - please could you give a (practical) example of code where
On Sun, Apr 23, 2017 at 11:52 PM, Jonathon Delgado
wrote: the a tuple could realistically be passed to length, but you don't know what the answer will be at compile time? Michael Orlitzky - everything in .NET has to descend from Object
because of it's OO design. Why does tuple have to implement Foldable if it doesn't provide any useful functions?
Thank you very much everyone in this thread for helping me understand! _______________________________________________ Beginners mailing list Beginners@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
_______________________________________________ Beginners mailing list Beginners@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
Beginners mailing list Beginners@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners