<div><div><div dir="auto">I like this tuple for the range syntax. Definitely nicer. </div></div></div><div dir="auto"><br></div><div dir="auto">I’d favor (a,a)->a->a now that hvr has pointed it out.  (I think that order lends itself to slightly better specialization on partial applipkiation internally )</div><div><div dir="auto"><br></div><div dir="auto">After sleeping on it, I absolutely agree with david about uniform strictness is the best option.  I’ll help sandy reflect both of these things into the final code. </div><div dir="auto"><br></div><div dir="auto">And as lennart mentioned, Clamp is bog standard.</div><div dir="auto"><br></div><div dir="auto">  And amusingly enough, the stranger bits of how min and max in the c standards interact with nans and infinities (avoiding rather than poisoning) are due to wanting clamping for rendering plots to be simple to write in c!</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Aug 15, 2020 at 5:59 AM Herbert Valerio Riedel <<a href="mailto:hvr@gnu.org" target="_blank">hvr@gnu.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><br>
> It seems to me that base is missing the very standard function `clamp ::<br>
> Ord a => a -> a -> a -> a`:<br>
><br>
> ```haskell<br>
> clamp :: Ord a => a -> a -> a -> a<br>
> clamp low high = min high .max low<br>
> ```<br>
><br>
> I propose it be added to Data.Ord. It's useful, generic, and non-trivial to<br>
> get right (the "big" number goes with "min" -- causes me cognitive<br>
> dissonance every time.)<br>
<br>
I'm -1 on the proposed type-signature.<br>
<br>
For one, while the motivation mentions cognitive overhead, it's ironic<br>
that the proposed<br>
<br>
  :: Ord a => a -> a -> a -> a<br>
<br>
with three `a`-typed parameters whose grouping/semantics is all but<br>
obvious if you merely see the type-signature without knowing its<br>
implementation is itself a source of cognitive overhead IMO.<br>
<br>
On the other hand, there are already related functions taking<br>
lower/upper bounds defined by the Haskell Report, see<br>
<br>
<a href="https://www.haskell.org/onlinereport/haskell2010/haskellch19.html#x27-22500019" rel="noreferrer" target="_blank">https://www.haskell.org/onlinereport/haskell2010/haskellch19.html#x27-22500019</a><br>
<br>
and so it'd help to kill two birds with one stone by align the proposed<br>
`clamp` with the precedent established by the pre-existing functions in<br>
Data.Ix, such as<br>
<br>
,----<br>
| class Ord a => Ix a where<br>
|<br>
|   range :: (a, a) -> [a]<br>
|       The list of values in the subrange defined by a bounding pair. <br>
|    <br>
|   index :: (a, a) -> a -> Int<br>
|       The position of a subscript in the subrange. <br>
|    <br>
|   inRange :: (a, a) -> a -> Bool<br>
|       Returns True the given subscript lies in the range defined the bounding pair. <br>
|    <br>
|   rangeSize :: (a, a) -> Int <br>
|        The size of the subrange defined by a bounding pair.<br>
`----<br>
<br>
So by grouping the type-signature like<br>
<br>
  clamp :: Ord a => (a,a) -> a -> a<br>
<br>
or even<br>
<br>
  clamp :: Ord a => a -> (a,a) -> a<br>
<br>
it becomes a lot more obvious which parameters are the bounds and which<br>
is the subject it's operating upon and it's IMO less error-prone as<br>
there's now less risk to accidentally swap parameters around.<br>
<br>
Moreover, this turns `clamp` into a function taking two parameters,<br>
thereby allowing `clamp` to be used as infix operator<br>
<br>
  (lower,upper) `clamp` x<br>
<br>
Having lower/upper bounds represented as tuple also makes it easier to<br>
define constants denoting the bounds, c.f.<br>
<br>
| ... = f (clamp int7Bounds x) ...<br>
|   where<br>
|     int7Bounds = (0,127)<br>
<br>
Long story short, I'm -1 on the proposed type-signature; I'm<br>
not against using a type-signature which groups the bounds-parameter<br>
into a tuple in alignment with the "Data.Ix" API.<br>
<br>
-- hvr<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></div>
</div>