There you go. That just needs a very light syntactic sugar and it's there. The elements of the lists are constants, so you want to use a literal, and the quoting of that can all be hidden. The (list ...) around the incoming expressions can be trivially hidden also.
The one thing I suspect match probably doesn't do is feature a fall-through mechanism that I alluded to; say we want (other-thing) for its side-effect, and then still evaluate (etc) if (> x y).
(Under no circumstances do we want fall-through to be opt-out, like in the C switch statement with its forgotten break bugs, but opt-in.)
Also, this mechanism could be optimized. Since the pattern lists must only contain #t, #f and _, they can be validated to contain nothing else. Accordingly, they can be arithmetically encoded (two bits per symbol), and subject to a numeric dispatch. '(#f _ #t) is a six bit number; '(_ #f #f) is another six-bit number and so on. Arguably, match itself could do that, but it's rather specialized.
The one thing I suspect match probably doesn't do is feature a fall-through mechanism that I alluded to; say we want (other-thing) for its side-effect, and then still evaluate (etc) if (> x y).
(Under no circumstances do we want fall-through to be opt-out, like in the C switch statement with its forgotten break bugs, but opt-in.)
Also, this mechanism could be optimized. Since the pattern lists must only contain #t, #f and _, they can be validated to contain nothing else. Accordingly, they can be arithmetically encoded (two bits per symbol), and subject to a numeric dispatch. '(#f _ #t) is a six bit number; '(_ #f #f) is another six-bit number and so on. Arguably, match itself could do that, but it's rather specialized.