Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Haskell's Either isn't intended to be used solely as Left = Err and Right = Ok. It's supposed to work as an abstract concept of "one thing or another", and the language designers have avoided choices that would canonicalize it that way, such as introducing a MonadFail (Either String) instance.

One example of why you would buck the trend would be to use of Left = Ok and Right = Err for a series of "retry" computations. Say you have a few functions of type Either a String, which all get progressively slower, but which work on progressively more advanced input. An example might be a series of regex engines, each of which run slower but handle more and more advanced lookahead syntax. You can then write something like:

    makeRegex :: String -> Either Regex ParseError
    makeRegex regexExpression = makeBasicRegex regexExpression >> makeLookaheadRegex regexExpression
This will return a Regex using a simple parser if it can, and if that function fails (by returning a Right value!) it will go onto the next function and try that.


Fun bit of history: Rust used to have Either. Eventually we added Result. At some point, we looked at all the code that existed (ahhh, the things you can do when you're young) and nobody used Either, only Result.

Today, either lives on as a package: https://crates.io/crates/either It gets a lot of downloads because it is actually used by a few popular libraries: https://crates.io/crates/either/reverse_dependencies


Either also lives on in the `futures` library, where it is used when you have multiple things that can happen in your asynchronous task and you want to stick to static types rather than returning a trait object.

https://docs.rs/futures/0.1/futures/future/enum.Either.html


A use-case I've had for a quick right-biased Java Either I threw together is handling a migration from java.util.Date to java.time.LocalDate:

    List<LocalDate> dobs = users.stream()
        .map(person -> Either.either(person::getDeprecatedDob, person::getDobLocalDate))
        .map(oldOrNewFormat -> oldOrNewFormat.fold(
            (Date oldFormat) -> convertOldFormatToNew(oldFormat),
            (LocalDate newFormat) -> newFormat,
         ))
        .collect(Collectors.toList());
I use the right-biased-ness of the Either to prefer the new format, if available, but failing that, use the old format and then convert as needed.


This could be accomplished using Optional#orElseGet without any additional library dependencies, though.


That's true. I didn't think of doing that. Nice!


This sounds clever at the expense of readability. Creating an explicit fallback mechanism for a Result would imo be preferable.


It's not clever for its own sake. Haskell is rooted in math and Either is logical disjunction. Its semantics is precisely that. Error handling is a specific use-case that can be implemented with Either. Rust as a language is more pragmatic. In real-world industrial code the concept of Either is predominantly used for error handling and thus Rust named their data constructors aptly.


Interesting use case. I honestly only saw either up until now as a more advanced maybe




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: