3 ms·

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

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.
    - justinhj 8y ago
      Well I guess car and cdr literally were CPU instructions back in the day, but it doesn't really make you a low level language in the way that C is. i.e: The entire language is really a thin wrapper over the assembly language which itself is an abstraction of the byte code. Most languages have arithmetic and more advanced mathematical operators that reflect actual op codes in the cpu, but that doesn't make those low level either.
      - lispm 8y ago
        The expectation is still that cons cells and the operators CAR and CDR can be implemented very efficiently. A CONS cell will on a typical machine be just two machine words - on a Lisp Machine it was sometimes just one machine word - when the cons cell was a part of a linear list. If you look at an unsafe CAR operation, it is often just a single machine instruction. Take this function which calls FOO twice. FOO is just calling CAR and inlining this call. (defun bar (a) (declare (optimize (speed 3) (safety 0) (debug 0)) (type cons a) (inline foo)) (the cons (foo (the cons (foo a))))) The disassembly then shows that CAR is a MOV instruction: ; Size: 14 bytes. Origin: #x1002FB5E49 ; 49: 488B40F9 MOV RAX, [RAX-7] ; no-arg-parsing entry point ; 4D: 488B50F9 MOV RDX, [RAX-7] ; 51: 488BE5 MOV RSP, RBP ; 54: F8 CLC ; 55: 5D POP RBP ; 56: C3 RET For a language like Lisp this is low-level stuff: telling the compiler to optimize for speed, no runtime checks, provide no debug information, declare the type of a variable, declare return types and instruct the compiler to inline a function. Or take structures in CL. They are defined such that can be compiled to a linear vector-like data structure with slot-access to known and static offsets. No redefinition, no meta-data information - low overhead. Two of the original goals of Common Lisp were defined as this: > Portability > Common Lisp intentionally excludes features that cannot be implemented easily on a broad class of machines. On the one hand, features that are difficult or expensive to implement on hardware without special microcode are avoided or provided in a more abstract and efficiently implementable form. (Examples of this are the invisible forwarding pointers and locatives of Zetalisp. Some of the problems that they solve are addressed in different ways in Common Lisp.) On the other hand, features that are useful only on certain ``ordinary'' or ``commercial'' processors are avoided or made optional. (An example of this is the type declaration facility, which is useful in some implementations and completely ignored in others. Type declarations are completely optional and for correct programs affect only efficiency, not semantics.) Common Lisp is designed to make it easy to write programs that depend as little as possible on machine-specific characteristics, such as word length, while allowing some variety of implementation techniques. > Efficiency > Common Lisp has a number of features designed to facilitate the production of high-quality compiled code in those implementations whose developers care to invest effort in an optimizing compiler.

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.
  - justinhj 8y ago
    Well I guess car and cdr literally were CPU instructions back in the day, but it doesn't really make you a low level language in the way that C is. i.e: The entire language is really a thin wrapper over the assembly language which itself is an abstraction of the byte code. Most languages have arithmetic and more advanced mathematical operators that reflect actual op codes in the cpu, but that doesn't make those low level either.
    - lispm 8y ago
      The expectation is still that cons cells and the operators CAR and CDR can be implemented very efficiently. A CONS cell will on a typical machine be just two machine words - on a Lisp Machine it was sometimes just one machine word - when the cons cell was a part of a linear list. If you look at an unsafe CAR operation, it is often just a single machine instruction. Take this function which calls FOO twice. FOO is just calling CAR and inlining this call. (defun bar (a) (declare (optimize (speed 3) (safety 0) (debug 0)) (type cons a) (inline foo)) (the cons (foo (the cons (foo a))))) The disassembly then shows that CAR is a MOV instruction: ; Size: 14 bytes. Origin: #x1002FB5E49 ; 49: 488B40F9 MOV RAX, [RAX-7] ; no-arg-parsing entry point ; 4D: 488B50F9 MOV RDX, [RAX-7] ; 51: 488BE5 MOV RSP, RBP ; 54: F8 CLC ; 55: 5D POP RBP ; 56: C3 RET For a language like Lisp this is low-level stuff: telling the compiler to optimize for speed, no runtime checks, provide no debug information, declare the type of a variable, declare return types and instruct the compiler to inline a function. Or take structures in CL. They are defined such that can be compiled to a linear vector-like data structure with slot-access to known and static offsets. No redefinition, no meta-data information - low overhead. Two of the original goals of Common Lisp were defined as this: > Portability > Common Lisp intentionally excludes features that cannot be implemented easily on a broad class of machines. On the one hand, features that are difficult or expensive to implement on hardware without special microcode are avoided or provided in a more abstract and efficiently implementable form. (Examples of this are the invisible forwarding pointers and locatives of Zetalisp. Some of the problems that they solve are addressed in different ways in Common Lisp.) On the other hand, features that are useful only on certain ``ordinary'' or ``commercial'' processors are avoided or made optional. (An example of this is the type declaration facility, which is useful in some implementations and completely ignored in others. Type declarations are completely optional and for correct programs affect only efficiency, not semantics.) Common Lisp is designed to make it easy to write programs that depend as little as possible on machine-specific characteristics, such as word length, while allowing some variety of implementation techniques. > Efficiency > Common Lisp has a number of features designed to facilitate the production of high-quality compiled code in those implementations whose developers care to invest effort in an optimizing compiler.