osa1 github gitlab twitter cv rss

Unboxed sums FAQ

July 22, 2016 - Tagged as: en, haskell, ghc.

The unboxed sums patch that implements unlifted, unboxed sum types (as described in this Wiki page) was merged yesterday, and a /r/haskell discussion emerged shortly after. As the implementor, I tried to answer questions there, but to keep answers more organized I wanted to write a blog post about it.

The reason I’m not writing this to the Wiki page is because this is about current plans and status of the feature. The wiki page may be updated in the future as the feature evolves and/or may be edited by others. This page reflects the current status as of today, future plans, and my own ideas.

Syntax is awful, why?

This feature is designed to complement the similar feature for product types (tuples), called “unboxed tuples”. The syntax is thus chosen to reflect this idea. Instead of commas in the unboxed tuple syntax, we used bars (similar to how bars used in sum type declarations). The syntax looks bad for several reasons:

Note that the original Wiki page for unboxed sums included a “design questions” section that discussed some alterantive syntax (see this version). Nobody made any progress to flesh out the ideas, and I updated the Wiki page to reflect the implementation. So it was known that the syntax is not good, but it just wasn’t a major concern.

Answer to the second question is also an answer to this question.

How is this supposed to be used by users?

We’re not expecting users to use this type extensively. It’ll mostly be used by the compiler, for optimizations. In fact, we could have skipped the front-end syntax entirely, and it’d be OK for the most part. If you haven’t used unboxed tuples before, you probably won’t be using unboxed sums.

The only place you may want to use this syntax is when you’re writing a high-performance library or program, and you have a sum type that’s used strictly and can take advantage of removing a level of indirection.

How is this used by the compiler?

A detailed answer would take too long, but here’s a summary:

Note that none of these need a concrete syntax for unboxed sums.

Hopefully this clarifies some questions and concerns, especially about the syntax. We have plenty of time until the first RC for 8.2 (mid-February 2017), so it’s certainly possible to improve the syntax, and I’ll be working on that part once I’m done with the optimizations.