3 ms·

> Clojure adds syntax, which breaks some of the inherent symmetry of Lisp slightly[0]. In what way does this break the symmetry? Lisp source code is a Lisp da

by nathell 14y ago

> Clojure adds syntax, which breaks some of the inherent symmetry of Lisp slightly[0]. In what way does this break the symmetry? Lisp source code is a Lisp data structure (or becomes one when read by the reader). In Common Lisp and Scheme, that structure is either an atom (an integer, a string, a symbol, etc.), or a list consisting of cons cells. In Clojure, that structure can also be a vector or a map. This is enabled by the fact that vectors and maps have their own literal syntax. I was uneasy about this in the beginning as well, but then I came to the conclusion that this is not unlispy at all.

chimeracoder 14y ago
Symmetry may not have been the correct word, since it does provide referential transparency but it certainly does add an extra layer of complexity to the parsing, even if it's only one extra step. Furthermore, I would argue that the additional syntax isn't necessary, which is my biggest beef with it - since you can convey the semantics of a vector or a map without altering the syntax at all, there's no reason to complicate the syntax any more than needed. > In Common Lisp and Scheme, that structure is either an atom (an integer, a string, a symbol, etc.), or a list consisting of cons cells. Let me fix that for you: in other Lisps, an item is either an atom or a cons cell. There's "no such thing" as a list in Lisp. There's a huge difference between having an option with two outcomes (S -> atom | cons) and an option with three outcomes. In computer science, we count "zero, one, many" - booleans are an example of this. By adding a third option, we've stepped out of the realm of the binary into the "many", and that's a much messier world to deal with.
- nathell 14y ago
  > I would argue that the additional syntax isn't necessary, which is my biggest beef with it - since you can convey the semantics of a vector or a map without altering the syntax at all, there's no reason to complicate the syntax any more than needed. You could say the same about the quote, backquote, unquote and unquote-splicing syntactic sugar being built into the reader. It is redundant, and yet it's there in most Lisps -- because it helps readability/maintainability at the cost of the little complexity it adds. > Let me fix that for you: in other Lisps, an item is either an atom or a cons cell. In Common Lisp, it is only correct insofar as the language defines "atom" as "not a cons cell" [1], contrary to the intuitive understanding that it's an indivisible entity. E.g., CL vectors are atoms, even though they have more in common with lists than, say, symbols. And they do have literal syntax, like #(1 2 3). How is that different from Clojure's [1 2 3], save the different type of parens? [1]: http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/typ_atom.html#atom http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec...
  - lispm 14y ago
    This has been in Lisp since the big flood.
lispm 14y ago
Common Lisp: * #(1 2 3) #(1 2 3) * (type-of #(1 2 3)) (SIMPLE-VECTOR 3)

by nathell 14y ago

chimeracoder 14y ago

Symmetry may not have been the correct word, since it does provide referential transparency but it certainly does add an extra layer of complexity to the parsing, even if it's only one extra step. Furthermore, I would argue that the additional syntax isn't necessary, which is my biggest beef with it - since you can convey the semantics of a vector or a map without altering the syntax at all, there's no reason to complicate the syntax any more than needed. > In Common Lisp and Scheme, that structure is either an atom (an integer, a string, a symbol, etc.), or a list consisting of cons cells. Let me fix that for you: in other Lisps, an item is either an atom or a cons cell. There's "no such thing" as a list in Lisp. There's a huge difference between having an option with two outcomes (S -> atom | cons) and an option with three outcomes. In computer science, we count "zero, one, many" - booleans are an example of this. By adding a third option, we've stepped out of the realm of the binary into the "many", and that's a much messier world to deal with.

nathell 14y ago
> I would argue that the additional syntax isn't necessary, which is my biggest beef with it - since you can convey the semantics of a vector or a map without altering the syntax at all, there's no reason to complicate the syntax any more than needed. You could say the same about the quote, backquote, unquote and unquote-splicing syntactic sugar being built into the reader. It is redundant, and yet it's there in most Lisps -- because it helps readability/maintainability at the cost of the little complexity it adds. > Let me fix that for you: in other Lisps, an item is either an atom or a cons cell. In Common Lisp, it is only correct insofar as the language defines "atom" as "not a cons cell" [1], contrary to the intuitive understanding that it's an indivisible entity. E.g., CL vectors are atoms, even though they have more in common with lists than, say, symbols. And they do have literal syntax, like #(1 2 3). How is that different from Clojure's [1 2 3], save the different type of parens? [1]: http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/typ_atom.html#atom http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec...
- lispm 14y ago
  This has been in Lisp since the big flood.

lispm 14y ago

Common Lisp: * #(1 2 3) #(1 2 3) * (type-of #(1 2 3)) (SIMPLE-VECTOR 3)