{ fromMaybe, fromLeft, fromRight, fromEither, fromThese, fromDynamic, … } extracts “the” value out of a { Maybe, These, Dynamic, … } with a suitable default if “it” isn’t present.
These functions map a type onto the smallest product type that can represent the union of its possible values, taking defaults as needed to make the result total. They seem asymmetric at first glance because the structures of the input types differ, but they’re all doing the same thing.
More to the point, anecdotally, I see Haskell beginners often reaching for accessor functions like ‘head’ and ‘fromJust’ before they’ve internalised pattern matching. They do use total combinators like ‘fromMaybe’ if available (and if they’re aware of them), because these combinators are more convenient than ‘if isJust … then fromJust … else …’, and they only happen to be safer incidentally. It’s the familiar “get value or default” pattern, if they’ve programmed before, nothing to do with totality. So it seems sensible to me to plug the hole in the taxonomy.
I’m not sure how fromMaybe relates here. Could someone explain?
For the anti-categorical folks who dislike codiag or related names like trace (in linear algebra trace is the sum of the diagonal of a matrix as a scalar, an apt analogy I think), another name that I think is descriptive is collapse
Names bandied about so far:
Dedup
Codiag
Fromeither
Things I mentioned above : trace and collapse
Zooming out though, this operation is equiv to “either id id”, so I don’t really see how inventing a new name for this specific tiny snippet really helps anyone.
My instinct about fromEither's type was the same as Carter's, and I had to remind myself of fromMaybe. I like the name fromEither overall. Seems to fit well with precedent and is straightforward enough.
You may wish to compare with fromMaybe then, which probably also doesn't have the type you'd expect :) The type you have there is more like bifoldMap
On Thu, 17 Sep 2020, at 1:42 PM, Carter Schonwald wrote:
I’d expect fromEither to be
Either a b -> (a-> c )-> (b-> c) -> c
Nothing about the name fromEither is suggestive of the Either a a type
Regardless of having a more abstract version, I'm +1 on Jon's suggestion, and those names. fromEither is something I have reached for many many times and been surprised it's not within arms reach.
On Thu, 17 Sep 2020, at 7:16 AM, Jon Purdy wrote:
I’m strongly for these:
Data.Tuple.dup :: a → (a, a)
Data.Either.fromEither :: Either a a → a
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