7 ms·

I didn't say CL has no vectors or syntax, just that in Clojure using sets, maps and vectors, is much more similar to using lists than it is in CL.

lispm 8y ago
Common Lisp reads and writes vectors, has a simple syntax for them and provides a sequence abstraction over lists and vectors.
- justinhj 8y ago
  Operations that in Clojure require only changing the kind of brackets, in Common Lisp are more verbose and explicit. If you don’t see the clean syntax and simple utility in that then fair enough, but I do.
  - lispm 8y ago
    reading and reducing a list: CL-USER 109 > (reduce #'+ (read)) (1 2 3) 6 reading and reducing a vector: CL-USER 110 > (reduce #'+ (read)) #(1 2 3) 6 I've changed only the opening bracket.
    - justinhj 8y ago
      Did you change from map to reduce because map needs to be told what kind of sequence to create? In Clojure the literal syntax avoids that. In addition there is this caveat about the literal vector syntax in Common Lisp: You can use the #(...) syntax to include literal vectors in your code, but as the effects of modifying literal objects aren't defined, you should always use VECTOR or the more general function MAKE-ARRAY to create vectors you plan to modify.
      - lispm 8y ago
        The literal syntax has nothing to do with MAP. I can define a MAP which returns a vector or a list, depending on the input: CL-USER 111 > (defun maps (function sequence) (map (type-of sequence) function sequence)) MAPS CL-USER 112 > (maps #'1+ '(1 2 3)) (2 3 4) CL-USER 113 > (maps #'1+ #(1 2 3)) #(2 3 4) I can also write a compiler macro, so that the implementation is chosen at compile time, when a literal data object is used... stuff which a Common Lisp implementation already might do for MAP. Common Lisp chose to define the basic MAP to always specify the result sequence I want to create or NIL for no sequence. > You can use the #(...) syntax to include literal vectors in your code, but as the effects of modifying literal objects aren't defined, you should always use VECTOR or the more general function MAKE-ARRAY to create vectors you plan to modify. That's not different for lists and vectors. For both I need to know which I want to modify. Common Lisp has generic operations to create and copy sequences for that: I can call COPY-SEQ to copy the literal sequence or call MAKE-SEQUENCE to create the sequence type I want. Here (and in many other places) Common Lisp is a low-level language, which exposes these things to the programmer.
        justinhj 8y ago
        So you admit the syntax is not as brief or as clean when you lose Clojure's data structure literals, and you have to write additional code for each type to get there? You haven't even touched on sets, which in CL are not a built in type, even though there are functions that let you pretend a list is a set, it's not really the same thing when it's not an efficient underlying representation. Personally I wouldn't call Common Lisp a low level language. A programmable language sure. Low level implies being close to the machine architecture, which it clearly is not.
        e12e 8y ago
        I don't know car/cdr/cadr/caar etc might not be close to the current machine architecture... But to me at least it feels quite low level. Perhaps similar to some of the unfortunate parts of the jvm/byte code spec that held back/convoluted dynamic languages on the jvm for a long while.
  - jlg23 8y ago
    > If you don’t see the clean syntax and simple utility in that then fair enough, but I do. I see a "cleaner syntax in the example" but the fragments of code you don't like, the literals, are something that you won't see in production code except for a few constants maybe. The difference in ~"characters to change" for switching from list to vector is far smaller than the amount of characters spent on this thread... (edit: even over the lifetime of a programmer)
    - justinhj 8y ago
      It's not really about just saving characters, it's about the fact that vector, set and to some extent map can be used in Clojure code as if they are an equal citizen in the syntax to list. It saves valuable mental cycles that can be used on your actual problem instead.

lispm 8y ago

Common Lisp reads and writes vectors, has a simple syntax for them and provides a sequence abstraction over lists and vectors.

justinhj 8y ago
Operations that in Clojure require only changing the kind of brackets, in Common Lisp are more verbose and explicit. If you don’t see the clean syntax and simple utility in that then fair enough, but I do.
- lispm 8y ago
  reading and reducing a list: CL-USER 109 > (reduce #'+ (read)) (1 2 3) 6 reading and reducing a vector: CL-USER 110 > (reduce #'+ (read)) #(1 2 3) 6 I've changed only the opening bracket.
  - justinhj 8y ago
    Did you change from map to reduce because map needs to be told what kind of sequence to create? In Clojure the literal syntax avoids that. In addition there is this caveat about the literal vector syntax in Common Lisp: You can use the #(...) syntax to include literal vectors in your code, but as the effects of modifying literal objects aren't defined, you should always use VECTOR or the more general function MAKE-ARRAY to create vectors you plan to modify.
    - lispm 8y ago
      The literal syntax has nothing to do with MAP. I can define a MAP which returns a vector or a list, depending on the input: CL-USER 111 > (defun maps (function sequence) (map (type-of sequence) function sequence)) MAPS CL-USER 112 > (maps #'1+ '(1 2 3)) (2 3 4) CL-USER 113 > (maps #'1+ #(1 2 3)) #(2 3 4) I can also write a compiler macro, so that the implementation is chosen at compile time, when a literal data object is used... stuff which a Common Lisp implementation already might do for MAP. Common Lisp chose to define the basic MAP to always specify the result sequence I want to create or NIL for no sequence. > You can use the #(...) syntax to include literal vectors in your code, but as the effects of modifying literal objects aren't defined, you should always use VECTOR or the more general function MAKE-ARRAY to create vectors you plan to modify. That's not different for lists and vectors. For both I need to know which I want to modify. Common Lisp has generic operations to create and copy sequences for that: I can call COPY-SEQ to copy the literal sequence or call MAKE-SEQUENCE to create the sequence type I want. Here (and in many other places) Common Lisp is a low-level language, which exposes these things to the programmer.
      - justinhj 8y ago
        So you admit the syntax is not as brief or as clean when you lose Clojure's data structure literals, and you have to write additional code for each type to get there? You haven't even touched on sets, which in CL are not a built in type, even though there are functions that let you pretend a list is a set, it's not really the same thing when it's not an efficient underlying representation. Personally I wouldn't call Common Lisp a low level language. A programmable language sure. Low level implies being close to the machine architecture, which it clearly is not.
        e12e 8y ago
        I don't know car/cdr/cadr/caar etc might not be close to the current machine architecture... But to me at least it feels quite low level. Perhaps similar to some of the unfortunate parts of the jvm/byte code spec that held back/convoluted dynamic languages on the jvm for a long while.
- jlg23 8y ago
  > If you don’t see the clean syntax and simple utility in that then fair enough, but I do. I see a "cleaner syntax in the example" but the fragments of code you don't like, the literals, are something that you won't see in production code except for a few constants maybe. The difference in ~"characters to change" for switching from list to vector is far smaller than the amount of characters spent on this thread... (edit: even over the lifetime of a programmer)
  - justinhj 8y ago
    It's not really about just saving characters, it's about the fact that vector, set and to some extent map can be used in Clojure code as if they are an equal citizen in the syntax to list. It saves valuable mental cycles that can be used on your actual problem instead.