Process thoughts Re: clamp function in base

Glad it was a good experience for you! I think, especially for library proposals (though aspirationally For language/ compiler changes), any design /api /spec change greatly benefits from having a working matching patch we can engage with! This helps for both impact assessments when preexisting code might have a name collision or it’s a change in existing semantics. OR just for refining and improving corner cases. Such as ed pointing out how we can define clamp generically in a manner that has humane behavior for float and double. For stuff that’s too complicated to have a simple patch, I strongly encourage folks to email libraries with a request for feedback on an idea to get feedback or confidence in the direction before investing time into making. Such patches. This is not to say this should be ironclad. But I think it’s a workflow that helps everyone be on the same page and helps make sure we can move quickly when there’s clarity. As happened with sandys patch! On Fri, Sep 11, 2020 at 2:22 PM Sandy Maguire wrote:

My pleasure! Thanks for not letting the experience be a bureaucratic nightmare!

On Fri, Sep 11, 2020 at 11:19 AM Carter Schonwald < carter.schonwald@gmail.com> wrote:

...

Thanks for helping make this happen!

Should be merged In later today!

On Sat, Aug 15, 2020 at 2:19 PM Sandy Maguire wrote:

...

Sounds good. For whatever reason the tupled arguments make me feel better about the `high

On Sat, Aug 15, 2020 at 8:22 AM Emily Pillmore wrote:

...

+1, though, David has good points about unnecessary laziness. I'm fine with the name and the signature

``` clamp :: Ord a ⇒ (a,a) → a → a ```

(or some variation on the theme).

On Fri, Aug 14, 2020 at 5:38 PM, Sandy Maguire wrote:

...

Hi all,

It seems to me that base is missing the very standard function `clamp :: Ord a => a -> a -> a -> a`:

```haskell clamp :: Ord a => a -> a -> a -> a clamp low high = min high .max low ```

I propose it be added to Data.Ord. It's useful, generic, and non-trivial to get

right (the "big" number goes with "min" -- causes me cognitive

dissonance every time.)

Thanks, Sandy

_______________________________________________

Libraries mailing list

Libraries@haskell.org

http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________

Libraries mailing list

Libraries@haskell.org

http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries