Programming languages that support pattern matching support decision tables. This is an OCaml port of the FizzBuzz example (fixing a mistake where the result of the modulo is compared with T and F):
match n mod 3 = 0, n mod 5 = 0 with
| true, true -> "FizzBuzz"
| true, false -> "Fizz"
| false, true -> "Buzz"
| false, false -> string_of_int n
This a "cleaner" version that takes advantage of wildcards (which appear in the article, but not in the FizzBuzz):
match n mod 3, n mod 5 with
| 0, 0 -> "FizzBuzz"
| 0, _ -> "Fizz"
| _, 0 -> "Buzz"
| _, _ -> string_of_int n
Note that the article states, "two rows can’t overlap in what inputs they cover," but in case analyses expressions of PLs with pattern matching, two rows can share a non-empty set of common matches and the higher row will take precedence.
If you're not aware, indenting your code marks it as preformatted, and so won't wrap in HN. Code which is preformatted and not wrapped is really hard to read on mobile, and even on desktop the end of your code is cut off in a scroll box.
It's almost always easier to read if you don't indent it, though HN should probably fix their style sheets so it doesn't matter.
If I'm quoting something (another reason people often indent their comments) I will normally wrap the whole thing in * so that it is italicised.
I don't know a good way to make code stand out, maybe someone else has an idea.
for i in 0...100 {
switch (i % 3, i % 5) {
case (0, 0): print("FizzBuzz")
case (0, _): print("Fizz")
case (_, 0): print("Buzz")
case (_, _): print("\(i)")
}
}
def fizzbuzz(x) when is_integer(x) do
case {rem(x, 3), rem(x, 5)} do
{0, 0} -> "FizzBuzz"
{0, _} -> "Fizz"
{_, 0} -> "Buzz"
{_, _} -> Integer.to_string(x)
end
end
Why? It'd be a mapping from "patterns" (a concept that exists only within the language's compiler/interpreter) to executable closures. How is that any different from the AST of the match-expression in the GP's comment? And what would you do with that mapping, besides using it as an AST to generate code, perhaps after adding/removing some match clauses?
In this case, the most optimal representation of the data is the code.
I would go with a "compromise"; while decision tables should be "code", I think it could be nice if there was some syntatic sugar for making these tables actually tabular. Of course semantically it would be very much the same as a pattern match.
Why can't you do either of those things with the AST of the match-expression? And what stops you from leaving the code as code, and extracting that AST by calling into the compiler?
(Maybe I'm being unfair here. I write mostly Elixir, and it's really easy in Elixir—one or two lines—to extract the AST of the body of a function defined in a given file and then work with it. It's just as easy to hold data canonically in its AST representation, and then both analyze it, and generate code from it, at runtime.)
