<div dir="ltr"><div>This seems good for consistency since we provide corresponding functions for other basic types (bool, maybe, either). Sticking to consistent patterns would make Haskell's libraries easier to learn.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 11, 2021 at 1:11 AM George Wilson <george@wils.online> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I am weakly in favour of this.<br>
Having catamorphisms for these basic types seems handy, although I<br>
think I would personally almost always use a pattern match in the case<br>
of Ordering.<br>
<br>
Cheers,<br>
George<br>
<br>
On Sat, 2 Jan 2021 at 12:15, Ian Treyball <<a href="mailto:ict2102@columbia.edu" target="_blank">ict2102@columbia.edu</a>> wrote:<br>
><br>
> Good day,<br>
><br>
> In short, I think it would be nice to add the following ordering<br>
> function to the Data.Ord module:<br>
><br>
> -- | Case analysis for the 'Ordering' type. @'ordering' x y z o @<br>
> evaluates to @x@<br>
> -- when @o@ is 'LT', @y@ when @o@ is EQ, and evaluates to @z@ when @o@ is 'GT'.<br>
> ordering :: a -> a -> a -> Ordering -> a<br>
> ordering lt _  _  LT = lt<br>
> ordering _  eq _  EQ = eq<br>
> ordering _  _  gt GT = gt<br>
><br>
> This would be essentially analogous to the bool function from Data.Bool:<br>
><br>
> bool :: a -> a -> Bool -> a<br>
> bool f _ False = f<br>
> bool _ t True  = t<br>
><br>
> Because the bool function is the case-analysis for the Bool data type,<br>
> and the order of the parameters matches the order in which the<br>
> constructors are defined:<br>
><br>
> Data Bool = False | True<br>
><br>
> I decided it would be consistent to follow the same approach for the<br>
> ordering implementation and so I use the particular ordering (no pun<br>
> intended) for the parameters to also match the order of the<br>
> constructors:<br>
><br>
> Data Ordering = LT | EQ | GT<br>
><br>
> I will also add an example use case, here is how show could be<br>
> implemented using the proposed function (of course, we momentarily<br>
> assume it is not derived, for sake of simplicity):<br>
><br>
> instance Show Ordering where<br>
>   show :: Ordering -> String<br>
>   show = ordering "LT" "EQ" "GT"<br>
><br>
> Please let me know if you would wish for me to share more compelling<br>
> examples, I have a few, but they are longer (so not here included for<br>
> brevity's sake).<br>
><br>
> I hope the formatting comes out okay, I will link to a gist[1], just in case.<br>
><br>
> If this sounds acceptable, please let me know how to proceed (would<br>
> this fall under "Core Libraries Proposal"[2]? I don't necessarily see<br>
> adding this function as a breaking change, so I'm not sure, but I can<br>
> surely fill one out if it's appropriate); otherwise, thank you for<br>
> your time and consideration.<br>
><br>
> Respectfully,<br>
><br>
> Ian Treyball<br>
><br>
> [1] <a href="https://gist.github.com/subttle/b49762a929f25e349381ef161bbc33d0" rel="noreferrer" target="_blank">https://gist.github.com/subttle/b49762a929f25e349381ef161bbc33d0</a><br>
><br>
> [2] <a href="https://github.com/haskell-core/core-libraries-proposals" rel="noreferrer" target="_blank">https://github.com/haskell-core/core-libraries-proposals</a><br>
> _______________________________________________<br>
> Libraries mailing list<br>
> <a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>