<html>

  <head>

    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

  </head>

  <body>

    <blockquote type="cite"

cite="mid:CAB-2Q09Er3A36hfOwRsKdyPeD8L=JXWUDs6sJ2nE1QPrfpztLA@mail.gmail.com">

      <pre class="moz-quote-pre" wrap="">I am looking for a place where I can find or put some simple functions that I

expect but do not find in the `containers` or elsewhere in the standard

libraries.</pre>

    </blockquote>

For now, I can't see a good place for any of your suggestions.

      But maybe even discussing potential why-not's may further the

      discussion.<br>

    </p>

    <br>

    <blockquote type="cite"

cite="mid:CAB-2Q09Er3A36hfOwRsKdyPeD8L=JXWUDs6sJ2nE1QPrfpztLA@mail.gmail.com">

      <pre class="moz-quote-pre" wrap="">* Group a collection by an equivalence relation:

      classify ∷ Ord π ⇒ (a → π) → [a] → [[a]]

</pre>

    </blockquote>

    <p>If the provided function is indeed an "equivalence relation",

      shouldn't the type be <font face="monospace">Eq π ⇒ (a → π) → [a]

→ [[a]], which is basically <font face="monospace">Data.List.groupBy?

      On the other hand if the resulting list is supposed to be ordered,

      most practical applications will probably use a set or a map

      anyway.</p>

    <p>So the difference between this function and existing

      functionality is so small, that the cost of maintenance and

      remembering the name might not be worth it.<br>

    </p>

    <br>

    <blockquote type="cite"

cite="mid:CAB-2Q09Er3A36hfOwRsKdyPeD8L=JXWUDs6sJ2nE1QPrfpztLA@mail.gmail.com">

      <pre class="moz-quote-pre" wrap="">* From a finite map, get a map from its range to its fibers:

      fibers ∷ (Ord k, Ord v) ⇒ Map k v → Map v (NonEmpty k)

</pre>

    </blockquote>

    <p>Why <font face="monospace">NonEmpty</font>, and not <font

face="monospace">Set? Or any <font face="monospace">Monoid?

      And more importantly, who are we to decide? Again, the cost

      difference between maintaining and re-discovering one "standard"

      vs. re-implementing something more precisely suited to the task at

      hand via (e.g.) <font face="monospace">Data.Map.foldMapWithKey</font>

      doesn't seem worth it.<br>

    </p>

    <p>Additionally if I'm writing a program that would benefit from

      this function, performance considerations will almost always lead

      me to not use it. Instead, I will maintain both the map and its

      inverse from the start.</p>

    <p><br>

    </p>

    <blockquote type="cite"

cite="mid:CAB-2Q09Er3A36hfOwRsKdyPeD8L=JXWUDs6sJ2nE1QPrfpztLA@mail.gmail.com">

      <pre class="moz-quote-pre" wrap="">* Put a type into the diagonal of its square:

      diagonal = λx → (x, x)</pre>

    </blockquote>

Now this might fit into <font face="monospace">Data.Tuple.

      Then again, it's faster and more self-documenting to re-implement

      it at hoc than to remember a name.</p>

    <p>Also, this (again) is less useful than it seems. It will almost

      always require an application of <font face="monospace">uncurry</font>

      as well, which makes the program harder to understand. Sometimes

      it's better to replace both with a single application of the Monad

      instance of <font face="monospace">(->)</font> – or with the

      "real" function.<br>

    </p>

    <p>For example:</p>

    <pre><font face="monospace">uncurry (+) . diagonal ≡ join (+) </font><font face="monospace"><font face="monospace">≡</font> \x -> x + x </font><font face="monospace"><font face="monospace">≡</font> (2*)</font></pre>

    <p>Using <font face="monospace">diagonal</font> is probably one of

      the worst ways to implement this and many of its brethren.<br>

    </p>

    <p><br>

    </p>

    <blockquote type="cite"

cite="mid:CAB-2Q09Er3A36hfOwRsKdyPeD8L=JXWUDs6sJ2nE1QPrfpztLA@mail.gmail.com">

      <pre class="moz-quote-pre" wrap="">It is unfeasible to put them into the standard libraries. _(Attempts were made.)_</pre>

    </blockquote>

    <p>This sounds like the maintainers of the standard libraries had

      their own objections. I suspect some of them might be similar to

      the ones above. Which leads me to suspect you might not have taken

      their feedback to heart. Which might in fact be the biggest hurdle

      on getting your code accepted into a library.<br>

    </p>

    <p><br>

    </p>

  </body>

</html>