3 ms·
Associative data structures (maps / dicts) are super first-class in Clojure, in a way that they aren't in other Lisp-1's (at least from what I remember of dabbl
by neutronicus 9y ago
Associative data structures (maps / dicts) are super first-class in Clojure, in a way that they aren't in other Lisp-1's (at least from what I remember of dabbling in Racket). There's a literal syntax for them. Keywords are functions that you can call with a map as an argument. You can destructure them in `let` bindings. And so on.
In my opinion, this turns out to be a pretty major win. Code is still data, it's just that this data is a mix of lists, vectors, and maps, and now you can type associative data structures into your code as easily as you can lists. Hash tables in vanilla Common Lisp are a nightmare (there is a nice library that at least gives a Clojure-y initialization option via Reader macro), and a glance at the Racket documentation suggests the story there is probably not much better.
Clojure code in the wild uses the destructuring on maps a lot like, e.g. Haskell code uses pattern matching, and Spec is an interesting core library aimed at allowing libraries to insist that keys be present in maps and so on.
Anyway, I had occasion to interact with some Common Lisp code I'd written several years ago, and I was struck by how annoyed I was at it for not being Clojure. Part of that is the Lisp-2 issue, but I also really missed how lightweight and easy Clojure maps are, and how easy they are to use for control flow. (I will say that Clojure's clunky recursion annoys me, but much less than trying to deal with Hash Tables in CL)
Also, and I know you say you don't care about Java, but ... sometimes you have to interact with some annoying outside system (like, a database or a web browser), and there is a high-quality Java(Script) library that makes this task trivial and lets you work on what you want!
- joncampbelldev 9y agoAlso on the subject of clojure's data structures, they are all immutable by default (with structural sharing so changes are efficient, not just defensive copys). This greatly assists in writing functional, multi-threaded code. For original asker, see here for more details: https://clojure.org/reference/data_structures https://clojure.org/reference/data_structures
- flavio81 9y ago>Hash tables in vanilla Common Lisp are a nightmare I seriously disagree with such a statement. Also, i feel confused that a lisp being a Lisp-2 could be an "issue". Separate namespaces for functions, symbols, classes, labels and so on is great, because they dramatically simplify naming things, which is one very important task for writing clean, readable, maintenable code.
- threatofrain 9y agoAfter using a Lisp for awhile I've come to feel that privileged symbols improves ability to mentally acquire some code. It was an okay learning journey, but it left me hungering for an easier FP language, and it also solidified my intuition that simple is both easy and hard at the same time, and Lisp is simple.
- catnaroek 9y ago> Associative data structures (maps / dicts) are super first-class in Clojure “First-class”, you keep using that word. I do not think it means what you think it means. See here for the details: https://en.wikipedia.org/wiki/First-class_citizen https://en.wikipedia.org/wiki/First-class_citizen . tl;dr: First-class-ness is about semantics, not syntax. And, while every language (including Racket) is broken in some ways, it's not broken enough for associative data structures to be inexpressible in it. > There's a literal syntax for them. Why does this matter in a language with macros anyway?
- emidln 9y ago>> There's a literal syntax for them. > Why does this matter in a language with macros anyway If you don't have this, you end up with a bunch of read table syntaxes for the same thing. These usually don't play nicely together. See Common Lisp libraries (since CL doesn't provide this syntax in the standard) for all the subtly incompatible hash table read syntaxes and printer implementations you can stomach.
- catnaroek 9y agoThe solution to this specific problem is library standardization, not hardcoding more data structures into the core language.