It is possible, for example, to go through some books, especially "The Joy Of Clojure" which contains 20 line of marketing slogans for 1 line of code, and make explicit commentaries on all the subtle differences, but I'm not going to perform such a tedious task for free.)
> "The Joy Of Clojure" which contains 20 line of marketing slogans for 1 line of code
> but I'm not going to perform such a tedious task for free
Well, obviously there's no point in discussing this further and we have to agree to disagree. Have a nice day anyway.
(define (cross xs ys)
(cond ((or (null? xs) (null? ys)) '())
((atom? xs) (cons (list xs (car ys)) (cross xs (cdr ys))))
(else (append (cross (car xs) ys) (cross (cdr xs) ys)))))
(defun cross (xs ys)
(cond ((or (null xs) (null ys)) nil)
((atom xs) (cons (list xs (car ys)) (cross xs (cdr ys))))
(t (append (cross (car xs) ys) (cross (cdr xs) ys)))))
(defn cross2 [xs ys]
(cond (or (and (sequential? xs) (empty? xs)) (empty? ys)) '()
(not (sequential? xs)) (cons (list xs (first ys)) (cross2 xs (rest ys)))
true (concat (cross2 (first xs) ys) (cross2 (rest xs) ys))))
But I would argue that this interface is poorly designed, since you can say (cross2 '(a b c) '(1 2 3)) or (cross2 'a '(1 2 3)) but not (cross2 '(a b c) '1), and worse, (cross2 '(a (b c) d) '(1 2 3)) implicitly flattens the (b c) into individual items, which is probably a latent bug rather than desired behavior. So I would argue for writing it in this form instead:
(defn sc [x ys] ; scalar cross
(if (empty? ys) '()
(cons (list x (first ys)) (sc x (rest ys)))))
(defn cross [xs ys]
(if (or (empty? xs) (empty? ys)) '()
(concat (sc (first xs) ys) (cross (rest xs) ys))))
Except really, if this isn't a homework problem, I think you should write it like this in any of these three Lisps:
(defn cross [xs ys]
(map (fn [x] (map (fn [y] (list x y)) ys)) xs))One more subtle thing: your solution produces (((a 1) (a 2)) ((b 1) (b 2)) ((c 1) (c 2))) while the contract was to produce "list of all possible pairs".
(defn cross [xs ys]
(mapcat (fn [x] (map (fn [y] (list x y)) ys)) xs))
(defun cross (xs ys)
(loop for x in xs
appending (loop for y in ys
collect (list x y))))
I'm not sure I agree on (recur...). You would need to use (recur...) if you were translating tail-recursive code that iterated over something other than a data structure and didn't produce new live objects on every iteration. But the code you gave wasn't tail-recursive, and what it iterated over was a data structure, and every iteration produced live objects that can't be garbage-collected. Even if you rewrote it to be tail-recursive, it wouldn't run out of stack for reasonably-sized output lists anyway; and for unreasonably-sized output lists, it would be likely to run out of heap for the output before it ran out of stack. I'm interested to hear if you manage to get it to stack-overflow. (It seems likely to be possible, but perhaps a bit of a challenge.)
Regardless, I don't think it's reasonable to claim that languages that don't have tail-call elimination — which I suspect you may be on the point of doing — aren't Lisps. Many popular Lisps have had TCE, but many more Lisps haven't, and the CL standard doesn't require it.
Python, for example: def cross(xs, ys): return [[x, y] for y in ys for x in xs]
LOOP in disguise :) (at least to my (very possibly faulty) understanding.)
(defn cross [xs ys]
(for [x xs, y ys]
[x y]))This definition seems to exclude Common Lisp from being a Lisp. That might be a defensible position, but it does call into question how your definition of "Lisp" is useful to you. It also seems to exclude languages like Dylan, which are commonly regarded as Lisps by people far cleverer than me.
> What is a lisp?
It's a very good question. I think PG sums it up quite nicely in "Revenge of the Nerds" [1]. Although, now that I'm thinking about it, I'm not quite sure there's any point in classifying something as a Lisp or not...
Again, Lisp could be defined as a limited set of conventions/features. As long as some other features, such as CLOS added there is no problem, but if some features are broken, then it is not Lisp anymore. It is just doesn't walk like a duck.
Let's say that Clojure was developed with a "put everything useful together" or Ruby-approach, if you wish, which is very popular for scripting languages, while development of Scheme and other Lisp dialects was founded on "put only what is absolutely essential, and done right".
The first approach "stuff anything in" you could see almost everywhere. The second approach "research first, and do the best" is unpopular for the obvious reasons and could be rarely seen only in masterpieces, such as Gambit-C, nginx, old-school marvels such as Informix.
So, in my opinion, Clojure is much closer to Ruby than to Lisp (let's not be deceived by parentheses) - it is a scripting language (to quickly put everything together with variety of clever special syntax and fancy data-structures without much thinking about implementation details). This is, of course, most productive approach to coding - this is why people love scripting languages so much.
Your suggestion of "let's say ..." is based in what appears to be complete lack of familiarity with all of the languages involved. Providing useful libraries doesn't preclude having done things right. Supplying a bare minimum of libraries does not preclude having made them miserable. There are plenty of awkward moments in using Common Lisp libraries that have made this plain to me.
Your suggestion that "research first, and do the best" is unpopular for "obvious reasons" is just hand-waving. The "obvious reasons" that are left unstated here are that "research first and do the best" languages general suck, hard. They suck because they sit in toy environments for years while the "release early and iterate" languages flourish under constant adaptation to real world usage. Both will have warts. The latter will be worth using.
Suggesting that "Clojure is closer to Ruby that Lisp" is just silly. What lisp? Scheme and Common Lisp, both definitely Lisps, are easily as different from each other as Clojure is from either. Ruby's insane class monkey patching is closer to the type of advice you find in Common Lisp than the immutable datatypes and carefully conceived concurrency primitives found in Clojure. Common Lisps many different name classes are a horror found in few modern languages. There's nothing in Clojure's "clever special syntax" that many developers did not toy with using reader macros and other abominations. Your suggestion that the olders lisps data structures, usually cobbled together with a pattern of lists and a prayer, are somehow more thought through than Clojures is both ignorance and meanness combined. Yes, Common Lisp had many builtin and library added datatypes. No, it didn't stop alists and structure built from underlying alists from being its fondest love.
As for classifying Ruby and Clojure as "scripting" languages, please define "scripting" language. It's a meaningless term for nearly anything other than `bash`.
The differences between, say, Scheme and CL are few and subtle - #' and funcall syntax, behavior of nil, etc. all the foundational special forms and general function application rule are the same.
Of course, CL is a much bigger language, but all its features never broke the basis on which everything is founded - a few special forms, list structure, general evaluation rule with exceptions only for these special forms, each of which follow its own rules.
Most of CL's features are macros and libraries, so they do enrich the base language, without breaking it up.
https://github.com/clojure/clojure/blob/master/src/jvm/cloju...
Most Common Lisp implementations have their compiler written Common Lisp. The language is implemented and extended in Common Lisp.