4 ms·

I guess it's you who is just unfamiliar with the syntax. Do you find (+ 2 2) harder to understand that 2+2? If the code is well indented, IMHO it's quite under

by S4M 13y ago

I guess it's you who is just unfamiliar with the syntax. Do you find (+ 2 2) harder to understand that 2+2? If the code is well indented, IMHO it's quite understandable. For example, what do you think of this Lisp code snippet (it's not the best possible code, just some stuff I have at hand to show without you needing to know the context): ;;takes two list l1 and l2 of same length, and return (l1[0] l2[0] ;;l1[1] l2[1] ...) (defun mix (l1 l2) (if (null l1) nil (append (mix (cdr l1) (cdr l2)) (list (car l1) (car l2))))) EDIT: formatted the code as per gcr suggestion.

gcr 13y ago
In HN, use four spaces to indent code blocks, like this: ;;takes two list l1 and l2 of same length, and return (l1[0] l2[0] ;;l1[1] l2[1] ...) (defun mix (l1 l2) (if (null l1) nil (append (mix (cdr l1) (cdr l2)) (list (car l1) (car l2))))) (Also, for the record, you should say (append (list ...) (mix ...)) or else you'll reverse the result list, which I don't think is your intent)
- S4M 13y ago
  Thanks for the tip of the indentation, and for checking my code - you are right that I got the order wrong in (append (mix ...) (list ...)), but in this particular case I'm not interested in how my list is ordered.
- e12e 13y ago
  This shows off one of lisp's (INHO) unfortunate anachronisms, namely that your "other car is first". CDR and CAR refer to machine instructions on the IBM-704 that had a (by today's standards) a somewhat quaint handling of "words" in memory, roughly allowing CAR to refer to a data element at the head of a linked list, and CDR to refer to the pointer to the rest of the list (or the empty list) (As well as a CONS instruction to build a word in memory from for parts, including the two 15 bit values that CAR/CDR refer to)[1]. Lisp then extended this by allowing programmers to combine c(a|d)+r, to get the equivalent of second, third, first-of-second-sublist etc. I'm not convinced the succinctness is worth it -- apparently experienced lisp-coders disagree. The TL;DR is that if you don't know lisp, this code is the same as the above, and is a bit more intuitive: ;;takes two list l1 and l2 of same length, and return (l1[0] l2[0] ;;l1[1] l2[1] ...) (defun mix (list1 list2) (if (null list1) nil (append (mix (rest list1) (rest list2)) (list (first list1) (first list2))))) Other languages might use head and tail, rather than first and rest. I'll agree that list1 and list2 might not offer much more readability than l1 and l2 -- at least not with the comments given. [1] Most of this is paraphrased from wikipedia, and what I remember from various times I've tried to get started with lisp, without ever really getting entirely comfortable with the language. http://en.wikipedia.org/wiki/CAR_and_CDR http://en.wikipedia.org/wiki/CAR_and_CDR [edit: I didn't notice the comment about reversing the list, but I think it is rather obvious that (append rest list(first)) does indeed reverse the order...? I actually wondered if append had a strange order of parameters while I "rewrote" the code :-) ]
  - lispm 13y ago
    Basically nobody should write such code. As a style guide: use CAR and CDR on cons data structures. Use FIRST, REST, SECOND, ... on lists. Actually on day two of Lisp, fifty years ago, these patterns have been abstracted. Recursion of lists has been replaced by higher-order functions in many cases. (defun mix (list1 list2) (mapcan #'list list1 list2)) Above maps the function LIST over the two lists and concatenates the results.
    - e12e 13y ago
      Interesting, by looking up mapcan, I came across the Simplified Lisp Reference: http://jtra.cz/stuff/lisp/sclr/mapcan.html http://jtra.cz/stuff/lisp/sclr/mapcan.html Also linked from the resources-section of: http://gettingstartedwithcommonlisp.com/ http://gettingstartedwithcommonlisp.com/ I don't think I've come across the simplified reference before -- appears to be a good resource for those of us starting out with lisp -- striking a balance between all of CLOS and the sometimes simplistic presentation of text books.
      - lispm 13y ago
        There is also reference one can print out: http://clqr.boundp.org http://clqr.boundp.org A a redirect service for Common Lisp documentation: http://l1sp.org/html/ http://l1sp.org/html/ A search engine: http://lispdoc.com http://lispdoc.com
    - e12e 13y ago
      Hm, am I right in thinking that numbers are defined to be atoms in lisp. And also that there are limits to how one can use macros, in that you'd not be able to a) rename FIRST, as in (FIRST list) to 1 (or '1): (1 list) or ('1 list); and b) that you couldn't modify the syntax to "decompose"/parse a slice syntax like: (1:2 (list-of-lists)) (here 1:2 would mean for example first element of second sublist/cons) ? Now, you could of course write an interpreter for such a language in lisp, but am I correct in assuming that there's no reasonable way to get a (standard'ish) lisp to compile an expression like (1:2 ...) to the equivalent caadr(?)-like expression? I saw there's a library for clojure that adds "slice notation" -- but does so by adding a (slice x y list)-macro which of course is fine -- but it would seem that (x:y list) would give similar benefits to the cadr/cddr etc -- allowing selected subsets to be highly optimized, for example? (As well as offering concise syntax)

by S4M 13y ago

gcr 13y ago

In HN, use four spaces to indent code blocks, like this: ;;takes two list l1 and l2 of same length, and return (l1[0] l2[0] ;;l1[1] l2[1] ...) (defun mix (l1 l2) (if (null l1) nil (append (mix (cdr l1) (cdr l2)) (list (car l1) (car l2))))) (Also, for the record, you should say (append (list ...) (mix ...)) or else you'll reverse the result list, which I don't think is your intent)

S4M 13y ago
Thanks for the tip of the indentation, and for checking my code - you are right that I got the order wrong in (append (mix ...) (list ...)), but in this particular case I'm not interested in how my list is ordered.
e12e 13y ago
This shows off one of lisp's (INHO) unfortunate anachronisms, namely that your "other car is first". CDR and CAR refer to machine instructions on the IBM-704 that had a (by today's standards) a somewhat quaint handling of "words" in memory, roughly allowing CAR to refer to a data element at the head of a linked list, and CDR to refer to the pointer to the rest of the list (or the empty list) (As well as a CONS instruction to build a word in memory from for parts, including the two 15 bit values that CAR/CDR refer to)[1]. Lisp then extended this by allowing programmers to combine c(a|d)+r, to get the equivalent of second, third, first-of-second-sublist etc. I'm not convinced the succinctness is worth it -- apparently experienced lisp-coders disagree. The TL;DR is that if you don't know lisp, this code is the same as the above, and is a bit more intuitive: ;;takes two list l1 and l2 of same length, and return (l1[0] l2[0] ;;l1[1] l2[1] ...) (defun mix (list1 list2) (if (null list1) nil (append (mix (rest list1) (rest list2)) (list (first list1) (first list2))))) Other languages might use head and tail, rather than first and rest. I'll agree that list1 and list2 might not offer much more readability than l1 and l2 -- at least not with the comments given. [1] Most of this is paraphrased from wikipedia, and what I remember from various times I've tried to get started with lisp, without ever really getting entirely comfortable with the language. http://en.wikipedia.org/wiki/CAR_and_CDR http://en.wikipedia.org/wiki/CAR_and_CDR [edit: I didn't notice the comment about reversing the list, but I think it is rather obvious that (append rest list(first)) does indeed reverse the order...? I actually wondered if append had a strange order of parameters while I "rewrote" the code :-) ]
- lispm 13y ago
  Basically nobody should write such code. As a style guide: use CAR and CDR on cons data structures. Use FIRST, REST, SECOND, ... on lists. Actually on day two of Lisp, fifty years ago, these patterns have been abstracted. Recursion of lists has been replaced by higher-order functions in many cases. (defun mix (list1 list2) (mapcan #'list list1 list2)) Above maps the function LIST over the two lists and concatenates the results.
  - e12e 13y ago
    Interesting, by looking up mapcan, I came across the Simplified Lisp Reference: http://jtra.cz/stuff/lisp/sclr/mapcan.html http://jtra.cz/stuff/lisp/sclr/mapcan.html Also linked from the resources-section of: http://gettingstartedwithcommonlisp.com/ http://gettingstartedwithcommonlisp.com/ I don't think I've come across the simplified reference before -- appears to be a good resource for those of us starting out with lisp -- striking a balance between all of CLOS and the sometimes simplistic presentation of text books.
    - lispm 13y ago
      There is also reference one can print out: http://clqr.boundp.org http://clqr.boundp.org A a redirect service for Common Lisp documentation: http://l1sp.org/html/ http://l1sp.org/html/ A search engine: http://lispdoc.com http://lispdoc.com
  - e12e 13y ago
    Hm, am I right in thinking that numbers are defined to be atoms in lisp. And also that there are limits to how one can use macros, in that you'd not be able to a) rename FIRST, as in (FIRST list) to 1 (or '1): (1 list) or ('1 list); and b) that you couldn't modify the syntax to "decompose"/parse a slice syntax like: (1:2 (list-of-lists)) (here 1:2 would mean for example first element of second sublist/cons) ? Now, you could of course write an interpreter for such a language in lisp, but am I correct in assuming that there's no reasonable way to get a (standard'ish) lisp to compile an expression like (1:2 ...) to the equivalent caadr(?)-like expression? I saw there's a library for clojure that adds "slice notation" -- but does so by adding a (slice x y list)-macro which of course is fine -- but it would seem that (x:y list) would give similar benefits to the cadr/cddr etc -- allowing selected subsets to be highly optimized, for example? (As well as offering concise syntax)