4 ms·

I have had this discussion with (I believe) one of the maintainers of lumen before: but why the paren-free let? In the beginning of my lisp journey I would hav

• pankajdoharey 5y ago
  Clojure's style *let* is probably a limitation of the JVM's inability to do proper tailcalls.
  • bjoli 5y ago
    You must have misunderstood. I was referring to the binding syntax. Clojure does (let [a 5 b 6] ...) whereas scheme and common lisp does (let* ((a 5) (b 6)) ...) SRFI-71 trivially extends this to do multiple values: (let ((a b (produces-2-values X y))) ...) Which I extended to to pattern matching: (let ((a (head . tail) (produces-an-atom-and-a-list ...))) ...)
    • reitzensteinm 5y ago
      Clojure absolutely supports this. (let [[a b] lst]) will destructure lst, binding a as the first element and b as the second. The destructuring then recurses to implement your second example.
      • bjoli 5y ago
        That was not my complaint.
        • reitzensteinm 5y ago
          Well, OK then. Rereading your post hasn't made it clearer.
          • bjoli 5y ago
            I never claimed clojure couldn't do destructuring. That should be pretty clear. My complaint is that it isn't extensible without resulting to syntax that is very unlispy. My complaint is the de-parenification of let. Why this form? It is easier to type, maybe, but visually it removes the distinction between binding, and makes any future extensions (like if clojure would gain multiple value support - however unlikely) impossible. The strength of it is clearly visible SRFI-71 for scheme. Regular old let was trivially extensible to handle multiple values. And I trivially extended that to have pattern matching, without breaking any backwards compatibility.
            • reitzensteinm 5y ago
              I don't think it's just the syntax that's a roadblock - Clojure is not intended to be extensible in that way. For better or worse, it has batteries included and is highly opinionated. From that perspective, including parens in let just to enable some hypothetical extension makes no sense.
        • canadianfella 5y ago
          What is your complaint?
• 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 ago
    That 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 ago
      In 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 ago
        I 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).