4 ms·

My original post includes "there doesn't seem to be a compelling reason for ignoring it". I'm not arguing for tradition for tradition's sake. I don't think usi

My original post includes "there doesn't seem to be a compelling reason for ignoring it". I'm not arguing for tradition for tradition's sake. I don't think using = instead of define/defun/defn has a compelling reason. Clojure's use of [], {}, #(), etc., is compelling to me. I'm not a Lisp purist who thinks everything should be parentheses. Adding that syntax is helpful for the reader. Innovation is welcome when it's beneficial. = for assignment isn't.

kazinator 3y ago
Using [] to style function formal parameters is completely pointless. It literally serves no purpose. It just makes it gratuitously different from other languages (not only Lisps). In most mainstream languages, both formal parameters and actual parameters use parentheses. There would be a sense to it if square brackets shifted into some alternative semantics: (fn (...) ...) versus (fn [...] ...) doing something usefully different. If you must use square brackets there, they are just a syntactic quirk that doesn't enable any new semantics.
- hota_mazi 3y ago
  Everyone who uses Clojure, and even people who don't, but know Lisp, understand the point: since parentheses are used in Lisp to delineate everything, it makes sense to use a different pair of symbols to make parameter lists stand out more. Maybe saying it's "completely pointless. It literally serves no purpose" is a bit overly dramatic, don't you think? You could have limited yourself to saying you don't personally like it because it breaks with tradition.
  - kazinator 3y ago
    > it makes sense to use a different pair of symbols to make parameter lists stand out more. Quite simply, no, it doesn't. > you don't personally like it because it breaks with tradition. Nope! I don't impersonally like it, because it's a gratuitous inconsistency which doesn't do anything. It's not technically justified in any way. How does it make sense to have the formal parameter stand out? Why don't we want the function body to stand out? (fn (a b) [+ a b])? Don't the parameters already stand out by being on their own line (usually)? (defn (a b) ;; <-- sticks out like sore thumb ...) If you think something deserves to stand out in code, can't you teach your editor to highlight it? Where are the numbers to back all this "sense"?

kazinator 3y ago

Using [] to style function formal parameters is completely pointless. It literally serves no purpose. It just makes it gratuitously different from other languages (not only Lisps). In most mainstream languages, both formal parameters and actual parameters use parentheses. There would be a sense to it if square brackets shifted into some alternative semantics: (fn (...) ...) versus (fn [...] ...) doing something usefully different. If you must use square brackets there, they are just a syntactic quirk that doesn't enable any new semantics.

hota_mazi 3y ago
Everyone who uses Clojure, and even people who don't, but know Lisp, understand the point: since parentheses are used in Lisp to delineate everything, it makes sense to use a different pair of symbols to make parameter lists stand out more. Maybe saying it's "completely pointless. It literally serves no purpose" is a bit overly dramatic, don't you think? You could have limited yourself to saying you don't personally like it because it breaks with tradition.
- kazinator 3y ago
  > it makes sense to use a different pair of symbols to make parameter lists stand out more. Quite simply, no, it doesn't. > you don't personally like it because it breaks with tradition. Nope! I don't impersonally like it, because it's a gratuitous inconsistency which doesn't do anything. It's not technically justified in any way. How does it make sense to have the formal parameter stand out? Why don't we want the function body to stand out? (fn (a b) [+ a b])? Don't the parameters already stand out by being on their own line (usually)? (defn (a b) ;; <-- sticks out like sore thumb ...) If you think something deserves to stand out in code, can't you teach your editor to highlight it? Where are the numbers to back all this "sense"?