Simon Peyton Jones's "The implementation of functional programming languages" has a chapter on the "Efficient compilation of pattern matching" (chapter 5 by Philip Wadler).
Also Xavier Leroy's ZINC paper (https://xavierleroy.org/bibrefs/Leroy-ZINC.html) although I believe that's no longer the implementation used by OCaml since it got replaced by an even more efficient one.
It explains how to minimize the decisions trees you obtain from a match statement, so you gain a ton of efficiency over a naive implementation, especially for large, multi-column matches.
As someone who has implemented full match in several industrial languages: this isn’t really match; it doesn’t not handle unpacking. And that is by far the only interesting bit. This feature is more accurately called `cond` à la Scheme, and you can fully expand it away ahead of type checking. Looking at unpacking in the arms, even with Scheme’s truth-y values and `=>`, could be neat.
Optimizing well-known jumps is useful, as is branch reordering, but the tombstone flag is unnecessary; you can simply write down a list of all targeted / called blocks and perform dead block elimination more generally that way.
Simon Peyton Jones's "The implementation of functional programming languages" has a chapter on the "Efficient compilation of pattern matching" (chapter 5 by Philip Wadler).
https://simon.peytonjones.org/assets/pdfs/slpj-book-1987-2up...
Also Xavier Leroy's ZINC paper (https://xavierleroy.org/bibrefs/Leroy-ZINC.html) although I believe that's no longer the implementation used by OCaml since it got replaced by an even more efficient one.
Probably Compiling Pattern Matching to Good Decision Trees (by Luc Maranget) is the scheme used by OCaml (http://moscova.inria.fr/%7Emaranget/papers/ml05e-maranget.pd...).
It explains how to minimize the decisions trees you obtain from a match statement, so you gain a ton of efficiency over a naive implementation, especially for large, multi-column matches.
As someone who has implemented full match in several industrial languages: this isn’t really match; it doesn’t not handle unpacking. And that is by far the only interesting bit. This feature is more accurately called `cond` à la Scheme, and you can fully expand it away ahead of type checking. Looking at unpacking in the arms, even with Scheme’s truth-y values and `=>`, could be neat.
Optimizing well-known jumps is useful, as is branch reordering, but the tombstone flag is unnecessary; you can simply write down a list of all targeted / called blocks and perform dead block elimination more generally that way.
Golang is a blub language, so not really surprising.