JavaScript Isn't Scheme

So, just like Lisp, then.

You can do that with any language that has an eval function. Eval takes a string and feeds it into the interpreter.

Sure, Racket has differences from CL, but I don't see how havi any of the things you mention make it "not a Lisp" . Clearly, it's not CL, but you don't seem to be making the "CL is the only Lisp" argument.

You're mostly mistaken, and you've mostly been fooled by changing names.

Clojure lists aren't lazy, and they support the Lisp operations, under slightly different names, and with the same asymptotic performance characteristics you're used to, because they're made of chained cons cells. The cons operation is implemented at https://github.com/clojure/clojure/blob/master/src/jvm/cloju.... Your "more complex example" is a 1960 program written, originally, in M-expressions; here's the first definition on the cited p.32:

    th1r[v;a1;a2;c1;c2] = [atom[v] → member[v;a1]∨
        th[a1;a2;cons[v;c1];c2];T → member[v;a2]∨
        th[a1;a2;c1;cons[v;c2]]]

As far as I know, there hasn't ever been a Lisp system that could parse and run that, and certainly not LispWorks. But you can straightforwardly transliterate it either into Lisp 1.5, or Common Lisp (although the post you link doesn't bother; instead they wrote an interpreter for the incompatible Lisp 1.5 syntax in Common Lisp), or into Clojure:

    (defn th1r [v a1 a2 c1 c2]
        (cond (symbol? v) (or (some #{v} a1) (th a1 a2 (cons v c1) c2))
              true        (or (some #{v} a2} (th a1 a2 c1 (cons v c2)))))

The only weird thing here is using the set-membership test instead of MEMBER.

Compare the above to the LISP 1.5 version:

    (TH1R (LAMBDA (V A1 A2 C1 C2) (COND
        ((ATOM V) (OR (MEMBER V A1)
        (TH A1 A2 (CONS V C1) C2) ))
        (T (OR (MEMBER V A2) (TH A1 A2 C1 (CONS V C2))))
        )))

Clearly Lisp changed a lot between LISP 1.5 in 1962 and CLtL in 1984, not to mention current Common Lisp practice; what you'd write in any modern Lisp looks a lot more like the Clojure version than the LISP 1.5 version.

The set thing, though, points to a real difference in Clojure: it has a set data type, and you're expected to use it instead of the list data type when what you want is a set. It's still immutable, though, and supports efficient nondestructive update, so if you decide to rewrite this as

    (defn th1r [v a1 a2 c1 c2]
        (if (symbol? v)
            (or (a1 v) (th a1 a2 (conj c1 v) c2))
            (or (a2 v) (th a1 a2 c1 (conj c2 v)))))

you can be assured that you're not totally hosing your program's performance. It might get better, in fact, if the sets are large.

You could argue that adding sets (and finite maps) to Lisp is violating the underlying essence of Lisp, in which you use conses for everything, but in fact we already have vectors, hash tables, classes, structs, and closures in all of the other Lisps you're citing, none of which were present in the Ur-Lisp in 1960.

ATOM doesn't exist in Clojure, although you can define it. atom does, and yes, it does something totally different from what ATOM did historically.

By "persistent" Clojure means "immutable". That is, there's no RPLACA or RPLACD. But RPLACA and RPLACD weren't present in McCarthy's original proposal, and they're hardly central to Lispiness. You could even argue that their absence is Lispier, since it encourages functional programming and enables the compiler to optimize it better, and indeed Racket already abandoned them a few years back for that reason.

BTW, I was wrong about what you would have had to type at LISP 1.5's read-apply-print-loop. You would have had to type

    CAR ((QUOTE (1 2)))

for obvious reasons.

i was complimenting you.. ahh nevermind

Scheme does the same thing too:

scheme@(guile-user)> (define (foo) (write where-did-this-come-from)) ;;; <stdin>:1:14: warning: possibly unbound variable `where-did-this-come-from' scheme@(guile-user)> (define where-did-this-come-from "the damn global scope") scheme@(guile-user)> (foo) "the damn global scope"scheme@(guile-user)>

Munificent's assertion that this doesn't represent lexical scoping is wrong, but his assertion in another thread that with() is an exception to lexical scoping is correct, and therefore JS is not lexically scoped, just mostly lexically scoped.

I would argue that the order of declarations is part of the scoping rules. In your example the variable i is not yet in scope when the assignment is done, and thus the compiler complaints. But this is of course somewhat philosophical.

My first argument was that the order of statements is part of the lexical representation of code, and thus should effect the lexical scoping.

You could have designed a language like that, but Brendan didn't.

Exactly my point. I was just using CL as example because I think it would be hard to argue that it is not a Lisp yet the standard doesn't guarantee TCO.

> 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...

[1] http://www.paulgraham.com/icad.html

In fact, all non-toy Lisp implementation provide TCO - http://0branch.com/notes/tco-cl.html because, it seems, it's a natural feature of a Lisp system (Scheme just requires it).

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.

Well, you could do it this way:

    (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))))

which is pretty much exactly homologous, allowing for the detail that you can't ask if an atom is empty? in Clojure, cond (Arc-like) takes alternating conditions and consequents rather than condition-consequent pairs, and the spellings of the list operations no longer refer to IBM 709 machine instructions. Also, it works on any kind of sequences, not just lists, with of course a punishing performance overhead on sequences whose `rest` operation is slow.

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))))

which avoids those irregularities and makes the code easier to understand by removing misleading false symmetries.

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))