Deprecate Foldable for Either

[Artyom Kazak]

On 20 Mar 2017 3:31 a.m., "Tony Morris" <tonymorris at gmail.com> wrote:

What intuition exactly? Demonstrate it to me so that I may empathise with
it. What pain? Show it to me. Are you sure it's intuition and not something
else? How are you so sure?


Okay, I have to admit that in this particular instance it's not quite my
intuition which causes the pain. Or rather, it's a different kind of
intuition, which I have acquired from Haskell in particular – "I don't have
to be particularly careful about minor refactorings, because if I change
the type of one thing, the compiler will tell me what other things I have
to change if I want to preserve the logic of my code". The behavior of
'length' breaks this intuition because "I'll just pass a tuple here instead
of whatever I used before" stops being a (relatively) safe refactoring.

(I'm saying "relatively" because of the existence of other extremely
polymorphic things – e.g. 'Aeson.encode'. Luckily, they're much less common
than 'length'.)

(An example of a scenario which more closely fits what I originally had in
mind: Set.size is O(1), but HashSet.size is O(n) – this one was pretty fun
to hunt down when we found that our code was unexpectedly slow.
Unfortunately, I can not adequately expand the intuition behind my initial
judgment of "HashSet.size is surely fast", because it's hard to do at 4am.)

The pain is pretty easy to demonstrate: I had to waste a day recreating the
Foldable/Traversable hierarchy in a custom prelude to ensure that nobody in
my team would be bitten by a refactoring. It wasn't *that* painful, sure –
but it's somewhat scary to think that there might be dozens of other
refactor-unfriendly functions lurking in libraries we're using (and one day
they will come to bite us).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20170320/fb9b8752/attachment-0001.html>