I'm targeting only WASM at the moment. I wish I could get into Haskell, but I just can't read it. I really can't parse what's going on with types like `Result e t (Either e t)`.
In Haskell, Either is defined as
data Either a b = Left a | Right b
Contrast the definition of the Result type in Swift:
public enum Result<Success: ~Copyable & ~Escapable, Failure: Error> {
/// A success, storing a `Success` value.
case success(Success)
/// A failure, storing a `Failure` value.
case failure(Failure)
}
I'm not sure what the parent commenter meant when they claimed that "Result <e, t> of yours is a Result (e, t) in Haskell." In Haskell, `(e, t)` would be the pair type (the binary product type).
> The `Either a b` type in Haskell is equivalent to the `Result<T, Error>` type in other languages. The only difference is in the naming:
The Result <E, T> usually (C#, at the very least, most probably C++ and many other languages) should always be fully instantiated. One usually cannot construct a type "function" like Result <E,> that needs a single type argument to instantiate a full type. The partial application on type level is not there in most languages, including Rust (a result of a little googling).
The Haskell's Either type can be instantiated to Be a two-type-arguments function, one type argument function and, finally, a fully instantiated type like Either String Int.
This means that Result <E, T> type effectively has a single type argument, namely pair of types. The Either type has two type arguments and can be partially applied.
In particular, higher-kinded types are necessary to abstract over functors (or functions from types to types, * -> *). The list type constructor is a functor, and the partially applied type constructor `Either a` is also a functor. However, in languages without higher-kinded types, type variables can only be "ground types" (of kind *).
I don't agree with this statement:
> This means that Result <E, T> type effectively has a single type argument, namely pair of types. The Either type has two type arguments and can be partially applied.
The Result<T, E> type still takes two type arguments. The main distinction, in my view, is that Haskell allows types to be "higher-order." In fact, to be really pedantic, you could argue that the `Either` type in Haskell really takes one type argument, and then returns a function from types to types (currying).
This is kind of like the type-level equivalent to how many programming languages support some notion of function or procedure (and functions may have multiple arguments), but only more modern languages support higher-order functions, or allow variables to be functions.
[1] https://web.cecs.pdx.edu/~mpj/pubs/springschool95.pdf
This [2] paper generalizes exceptions, allowing them to be first class citizens of a language and even to be a exceptions-as-a-library.
[2] https://raw.githubusercontent.com/nbenton/nbenton.github.io/...
In (not only) my opinion, Haskell's greatness is in "what is a language feature in most languages is a library in Haskell." One can model type system of a language by embedding it as a library into a Haskell and then develop it further as a standalone language if one prefers such path.
I did that embed-as-library thing several times. It was of great help, especially in the embedded systems and hardware circuits domains.