Hacker News Reader

Comment by thesz | Hacker News Reader

  > But I'm unsure if there's a strong argument that resonates with me yet that the language shouldn't have exceptions at all.

Result <E, T> is the type Either e t in Haskell. And Either is a Monad: https://hackage-content.haskell.org/package/base-4.22.0.0/do...

This means you can have a computation inside Either e monad (notice missing result type) which can occasionally produce an exception, and these exceptions are checked (Either String cannot produce SNAFU-type exceptions, only textual descriptions of what was wrong).

So, if you are developing your language, please consider embedding it in Haskell first. That would allow you to experiment with different type representations, at the very least: Result <e, t> of yours is a Result (e, t) in Haskell, which is very distinct from Result e t (Either e t).

View on HN

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)`.

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: "Result" semantically implies error handling, while "Either" implies a more general usage as the alternative between two options. Either and Result are the binary sum type (the disjoint union between two types).

In Haskell, Either is defined as

    data Either a b = Left a | Right b

Note that in Haskell, type parameters are lowercase. Source code: https://gitlab.haskell.org/ghc/ghc/-/blob/3f5e8d80b32063d265...

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)
    }

Source code: https://github.com/swiftlang/swift/blob/256ff127c93d7e59a75f...

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:

This is false and misleading.

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.

You are right, in Haskell type constructors may be partially applied. In my opinion, this feature has less to do with any fundamental difference between `Either` in Haskell and `Result` in other languages, and more to do with Haskell's more powerful type system. In the same way, the pair type (a, b) in Haskell is also different from the pair types in other languages. This feature is called "higher-kinded types."

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.

The paper about type classes [1] includes exceptions as an example.

[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.

Reply on news.ycombinator.com