5 ms·
I know that the purpose of the page is to compare syntax of common lisp, racket, clojure, and emacs lisp. But some examples could be more idiomatic, for instanc
by sinsudo 4mo ago
I know that the purpose of the page is to compare syntax of common lisp, racket, clojure, and emacs lisp.
But some examples could be more idiomatic, for instance instead of
(defun add (a &rest b)
(if (null b)
a
(+ a (eval (cons '+ b)))))
One should avoid eval and use endp instead of null:
(defun add (a &rest b)
(if (endp b) a
(apply #'add (+ a (first b)) (rest b))))
- CodeArtisan 4mo agoShouldn't it be (+ a (apply + b))
- db48x 4mo agoAlmost. It should be (+ a (apply #'+ b)). Common Lisp is a Lisp-2, so a + in the argument position is assumed to be a variable named +, not the function named +, unless you specify otherwise.
- gus_massa 4mo agoNo, the idea is to assume for this example that + only can be used with two arguments and define a new function that can be used with any number of arguments.
- ludston 4mo agoWorse: Using recursion in Common Lisp isn't idiomatic, given that CL doesn't guarantee tail-call optimisation in the specification.
- dreamcompiler 4mo agoSigh. This again. All major Common Lisps support tail call optimization with proper declarations, with the exception of ABCL because it runs on the JVM. And those declarations are all identical or almost identical, so it's easy to write an implementation-specific macro to guarantee TCO if you need to do so. Some algorithms are easiest to express and read with looping constructs. For those algorithms, use looping constructs. Other algorithms are easiest to express and read with recursion. For those, use recursion. You shouldn't be afraid of recursion just because ANSI doesn't say TCO is guaranteed. You should be afraid of it if your code needs to run on ABCL, but otherwise, recur on.
- ludston 4mo agoSigh and yet it continues to be true. You can make a pragmatic decision and rely on tail call optimisation for your specific case, but if you are writing a CL library, then it is not idiomatic to use recursion in the same way that you would for Clojure or Scheme. Even with SBCL, for example, it doesn't have tail-call optimisation for all architectures at all optimisation levels.
- aidenn0 4mo agoI think it is fair to say that the CL community is divided on whether or not relying on TCO is idiomatic. I prefer to write my state-machines as transitioning with tail-calls, and I do get called for it. It's relatively easy to switch something written in that manner to using a loop with a trampoline, so I do so when my collaborators request it.
- ludston 4mo agoI wouldn't argue about things that are a matter of taste normally, except that I've had the experience where I've turned down optimizer settings in order to debug some code better and then the had stack overflow.
- deleted 4mo ago[deleted]
- aidenn0 4mo agoThe use of cl:eval alone is enough to make me believe that the CL column was never reviewed by an experienced CL programmer. I am now more suspicious of the other columns, which are languages I'm far less familiar with.
- TacticalCoder 4mo ago> I am now more suspicious of the other columns, which are languages I'm far less familiar with. It's not bad but for Clojure for example it says "nil is like null in Java" but null in Java is not falsy. And it also says that destructuring is "named parameters" but it's not so: it's just destructuring (and there are two examples of destructuring given: one for the "named parameters" which aren't named parameters, and one for "parallel assignment" of local variables). Nothing bad but it's not possible to go into much details in such a table.
- kscarlet 4mo ago(defparameter *a* '(1 2 3)) (setf (car *a*) 3) And this is undefined behavior because it mutates literal constant. I stopped reading further. The CL column is so bad.
- vindarel 4mo agoThe trap is using quote, with the list operator there are no issues: (defparameter *a* (list 1 2 3)) and of course, mutating top-level variables is bad style.