Anarki – Community-managed fork of the Arc dialect of Lisp (opens in new tab)

Thank you the map <list> makes more sense now.

And looks like an easy trap for misreading code ...

After RTFM, I can answer my own question:

> In Arc, data structures can be used wherever functions are, and they behave as functions from indices to whatever's stored there.

(quoted from the Arc tutorial)

So

   arc> (l 0)
   1

and so on. So the GP makes sense.

I think the list '(0 1 2) is behaving like the function — in CL syntax, sorry, I don't know Arc — (lambda (x) (elt '(0 1 2) x)). That is, the list is being treated as a sequence, which is a function from each index to the corresponding element.

First public release of Arc came not long after Clojure.

Clojure is definitely better thought out as a language, and while Arc has some interesting ideas around web development, it also doesn't have a module system, so everything is just loaded into the same global namespace, which is pretty insane.

Ah, that makes sense. The next main difference in my mind is ergonomic, but relies on this regularity: functional syntax for composition, negation, quoted application. There are also other syntax additions and in my experience they're well-chosen and go a long way.

It would be more correct to say that they can be coerced to a function with a special purposes (e.g. using a set as a function is an alias for checking whether an item exists).

To say they are functions would be incorrect. By the same logic, a keyword is would be a function.

If I understand it correctly, Lisp-2 is a way (not the only way!) of maintaining more intuitive semantics in the face of macros. If I write the following:

  (your-macro
    (let ((x (foo y))
      (bar x))))

I probably don't want the meaning of FOO or BAR to be up for grabs based on the expansion of YOUR-MACRO, and certainly not LET. Lisp-1s often have hygienic macros to deal with this concern, but not always.

A lot of the comments mention reasons. In my experience, once you get used to a lisp-2 programming in a lisp-1 feels limiting: you can’t just write

    (def str “foo”)

In Clojure, because you’ll shadow the builtin definition of str (which leads to really weird bugs). But, this means that there’s one more thing to think about when naming your variables.

Additionally, I think we’re pretty used to “separate namespaces” for nouns and verbs in normal languages: it’s fairly rare, for example, for the word “run” to be ambiguous between its noun use and it’s verb use, in the context of a sentence.

To a certain extent it's just syntax sugar. It's relatively easy to implement a lisp-1 with a macro in a lisp-2 and vice versa.

At this point I'm so used to lisp-2 that I make all sorts of silly mistakes when I program in a lisp-1. In English, a word could be a noun or a verb depending on its position in a sentence, so there is a parallel there. Whether or not it's a good thing is a matter of taste.

The only clearly objective difference is that lisp-1 is simpler, which is probably why most lisps created in the past 30 or so years are lisp-1s.

Yes, JavaScript also has a single namespace, like a Lisp-1.

The advantage of a Lisp-2 is that it makes macro writing easier; you can include calls to known functions in the expansion without having to deal with the possibility that those names have been shadowed.

A Lisp-2 can treat function bindings specially at the compiler level.

In addition to the simplified hygiene, one consideration is that Lisp dialects typically have mutable variables. But the ANSI-Lisp-style labels and flet forms bind functions immutably. Thus a compiler never has to suspect that a local function will change.

In TXR Lisp, developed a way to combine Lisp-2 and Lisp-1 into a single dialect, to get the best of both with almost no downsides. In a nutshell, the square bracket syntax performs Lisp-1 style evaluation: [a b c] means expand/evaluate a, b, c in the same mannner, and then treat the value of a as a callable object which receives the values of b c.

Furthermore, any arguments of [...] which are symbolic (after macro-expansion) are treated in a combined namespace which contains both function and variable bindings. When the symbol is global, if it has both kinds of bindings, preference is given to the variable.

This [a b c] is a sugar for (dwim a b c), which is a special operator that is recognized properly by the macro expander, interpreter and compiler, including the various shadowing corner cases between macro and ordinary bindings.

Thus, there is no reason to have to choose between Lisp-1 and Lisp-2.

However, the implementation is a bit more complicated than just Lisp-2 alone, never mind Lisp-1.

The most commonly expressed reason is that you should be able to use variable names like "list" without shadowing the list function.

Someone with insight mentioned that there was a belief that it would be easier to optimize separate namespaces, but that reality proved them wrong, but I haven't verified that claim.