> Well, and more syntax than S-expressions: it's got both objects and arrays as fundamental structures instead of just lists

Well, Common Lisp has both of those as fundamental atoms:

    #S(foo :bar 3)

    #(1 2 3)

The former creates an instance of a FOO struct with its BAR slot set to 3; the latter is a 3-item array.

And then CLOS objects, hash tables, regular expressions, etc. can be added with reader macros.

It's cool and I love it, but it's irrelevant in the context of a universal data exchange language. In such case, you'd want to have those primitives defined in the exchange language spec itself - even if you'd end up implementing them as reader macros in CL (which I don't recommend - reader macros turn your READs into EVALs, which you obviously shouldn't do on untrusted input).

> you'd want to have those primitives defined in the exchange language spec itself

I agree with this: certain things need to be in the spec.

> even if you'd end up implementing them as reader macros in CL (which I don't recommend - reader macros turn your READs into EVALs, which you obviously shouldn't do on untrusted input).

This I don't agree with, because technically #\( & #\" are reader macros … they're just very well-defined reader macros. Presumably a spec which defined hash tables, regular expressions or whatever would define them as well as the Lisp spec defines lists and strings (and if not, well — it's a bad spec!).

> I agree with this: certain things need to be in the spec.

That was my main point. In the second part of the comment I didn't mean to discourage use of reader macros - it was more of an aside that the general facility of CL-style reader macros literally makes READ "shell out" into EVAL, so you need to (diligently) disable it for untrusted input (or reimplement a limited READ by hand). So we can't say "oh, but S-exps in Common Lisp can have anything through reader macros". Presumably if hash table literals were specified as a part of basic syntax, we could depend on it being standard and part of the safe subset of READ's duties; as it is however, we can't depend on it for arbitrary inputs.

Yeah, didn't mean it that literally.

> it's got both objects and arrays as fundamental structures instead of just lists

I'm bit sad that various lisps never standardized on a format for this; had they, then maybe we would have S-expressions as a popular data interchange format.

They did. It's called Common Lisp.

Common Lisp doesn't have a standard representation of hash tables, unfortunately. Also, CL didn't clean up the Lisp space completely; right now, there are Schemes, there's Clojure, LFE, Hy, and bunch of other niche Lisps, each with their own idiosyncrasies around syntax.

> Common Lisp doesn't have a standard representation of hash tables, unfortunately.

Ah, but you mentioned objects & arrays, not hash tables grin. Agreed that hash tables would have been nice, although that does then get into issues such as canonical representations (which matter e.g. for hashing).

> Also, CL didn't clean up the Lisp space completely; right now, there are Schemes, there's Clojure, LFE, Hy, and bunch of other niche Lisps, each with their own idiosyncrasies around syntax.

It would be nice if folks who want to use Lisp would use Common Lisp rather than reïnventing various forms of more-or-less round wheel. It's a remarkably well-engineered language (not perfect, of course: argument order, upcasing, pathnames & environments all leap to mind as problematic areas), and so far as I can tell quite a bit better than any of the alternatives.

In particular, it'd be really nice to see people using Schemes for serious engineering work to use Lisp instead. It's just not well-suited to writing large systems, except by grafting on an ad-hoc, informally-specified, potentially bug-ridden subset of Lisp.

> Well, and more syntax than S-expressions: it's got both objects and arrays as fundamental structures instead of just lists

Which can easily be added to sexps (see EDN).

The S-expressions of mainstream Lisp dialects have objects and arrays. E.g. Common Lisp:

  ;; structure:
  #s(type :slot1 value1 :slot2 value2 ...)

  ;; vector:
  #(1 2 3 4)