5 ms·
> None of this would have been possible using a clojure-style let. Why? Clojure already supports pattern matching in its `let`, e.g. (let [[head & tail] (
by b3n 5y ago
> None of this would have been possible using a clojure-style let.
Why? Clojure already supports pattern matching in its `let`, e.g.
(let [[head & tail] (produces-a-list)] ...)
- bjoli 5y agoThat was not my complaint. My complaint is that the [id expr id expr ...] form has no benefits except for people disliking parens at the cost of making the let for impossible to extend in a backwards compatible way. SRFI-71 for scheme extends let with support for values, like so: (let ((q r (quotient/reminder 10 3))) ...) This for is then also extensible (I have added pattern matching on top of it). Clojure's is not. (let [q r (hyptohetical-2-value-quotient/reminder 10 3)] ...) Makes no sense in clojure.
- fulafel 5y agoIn Clojure land we're more picky about paren usage and we're used to variants of let that are named explicitly. if-let, when-let, reagent/with-let, letfn, etc.
- bjoli 5y agoI would say that all of those are different than what I am saying (if-let and it's ilk are a conditional form. But sure. Rich has done many great decisions with regards to clojure. This part is one of the few I don't agree with (and maybe regular bit-tries instead of rrb-trees).