5 ms·
Not idiomatic, but it looks like [core.match][1] could be used to "if error" unpack the map: (let [result (do-thing x y z)] (match [result] [{:ok
by MathMonkeyMan 2y ago
Not idiomatic, but it looks like [core.match][1] could be used to "if error" unpack the map:
(let [result (do-thing x y z)]
(match [result]
[{:ok false :message msg}]
{:ok false :message (format "do-thing failed: %s" msg)}
[{:ok true, :value value}]
(continue-computation-with value)))
meh
[1]: https://github.com/clojure/core.match/wiki/Overview https://github.com/clojure/core.match/wiki/Overview
- roenxi 2y agoWhat is the advantage there that justifies bringing in another dependency? You've already got a let for binding parts of result and could use cond from clojure.core instead of match. It'd be effectively identical.
- MathMonkeyMan 2y agoThe point of `match` is you can combine the destructuring with the conditional. It's also why Rich Hickey dislikes it.
- dustingetz 2y agoi don’t think core.match has worked out in practice for many prod projects for subtle reasons, there’s a je ne sais quoi about it that seems not quite right
- kokada 2y agoDo you have a list of those reasons? I find it curious that I really enjoy `match` in both Scala and Python. While it can be argued that Scala is a completely different beast than Clojure, Python is much closer (in the sense that both are dynamic typed languages).
- socksy 2y agoUnfortunately (IMO), `core.match` in Clojure is a macro provided by a library you have to install, rather than a builtin function as in Scala or Python. It’s a really cool demonstration of the power of lisps, since macros basically let you edit the code at compile time, rather than at runtime, and match is maybe the most extreme example of this as it’s really compiling down the match statement into completely different code, rather than treating it like a cond statement (more info on the match algorithm here: https://github.com/clojure/core.match/wiki/Understanding-the-algorithm https://github.com/clojure/core.match/wiki/Understanding-the...). However, when using macros there’s always some trade-offs — for example, you usually can’t treat them as a first class function, passing them around (although I’m not sure if that’s true for core.match tbf). Additionally, they can be confusing to debug because the code that you’re writing doesn’t match the code that’s actually being run… stack traces can be particularly weird. Finally, by not being a builtin, it doesn’t really feel blessed as a language feature, and if it’s a choice between case, condp, or cond, I’m going to reach for one of those before core.match, simply because I don’t have to add a new library, I can be sure that I’ll understand the stack traces, and most importantly I can be sure that others will understand the code better. The fact that destructuring is built into Clojure means that you can get sort of half of the use cases for match in the first place, so it ends up being quite rare when you’ll actually reach for it. I’m not sure exactly what Dustin was referring to exactly, but those are my gripes with it. I think it’s a shame, because `match` is a more powerful construct every time I’ve encountered it in other languages, and it’s one of the few things I really miss as a built in part of Clojure.
- dustingetz 2y agoit is hard to criticize this library rigorously, broadly i think the second sentence here is what’s important: core.match seems designed to demonstrate the power and potential of macros, which is decidedly not the same as being designed to solve some specific problem or use case. So it has a lot of quirks and rough edges. Nobody ever really ran with it past that to see where it might lead. And whatever that is, it will be subtly different than in langs where it is the fundamental control flow construct
- 2y ago
- deleted 2y ago[deleted]