Fork me on GitHub
#beginners
<
2024-07-08
>
growthesque11:07:04

how come Clojure has its own nil type instead of leveraging Java's null type as it does for some other types?

lassemaatta11:07:45

Can you expand? As far as I know nil is null.

daveliepmann11:07:53

> nil means "nothing". It also is the same thing in Clojure as Java null. It did not have to be, but it is. So you can rely on that. So nil means nothing, and it is the same value as Java null. So when you get back nulls from Java, they are going to say nil. nil is a traditional Lisp word. – rich, https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/ClojureForJavaProgrammers.md clojure to java programmers

growthesque11:07:38

so why isn't it called null then?

growthesque11:07:57

I saw the last sentence.

👍 1
growthesque11:07:46

is it an actual type or some special form that's the absence of types

daveliepmann11:07:28

> so why isn't it called null then? I really like this question, because the answer (generalized) applies to a lot of "why" questions about Clojure.

😀 1
growthesque11:07:59

Maybe Rich is paying homage to lisp with some of those choices.

daveliepmann11:07:13

more than homage IMO — I consider Clojure to be Common Lisp rebooted for Rich's needs: 1. on the jvm for reach and marketability 2. immutable & persistent core data structures – Clojure's sine qua non, the one thing Rich said was not possible to retrofit into CL 3. built on abstractions instead of concrete data structures (a distant third in terms of motivation – on par with other choices like deprecating car and cdr)

Alex Miller (Clojure team)12:07:30

Clojure is a Lisp, which traditionally uses nil

Mario G13:07:06

I have a sense of nil explicitly hinting at my name here is nil because I'm trying to embrace Lisp nil-punnig (AKA being a bit more forgiving and not throwing all the time) but still double check what you're targeting (e.g. you're going to be good with Clojure maps, less so with plain Java concretions) If it was called null, this would be implicit and (to me) more confusing

growthesque14:07:50

I just realized that the way (cons item coll) and (conj coll item) 's parameters are positioned it makes it very easy to remember where the item will go. not sure if this is intentional or a happy coincidence.

👍 1
growthesque14:07:08

at least for vectors

andy.fingerhut14:07:06

There is probably an article on http://clojure.org somewhere that I do not have handy at the moment, but here is some discussion from years back in the Clojure Google group from folks that designed the APIs: https://groups.google.com/g/clojure/c/iyyNyWs53dc

andy.fingerhut14:07:13

That thread is linked from this StackOverflow page, and the SO page has links to a few other places, too: https://stackoverflow.com/questions/50275513/rules-of-thumb-for-function-arguments-ordering-in-clojure

🙏 1
Alex Miller (Clojure team)14:07:14

as a general rule of thumb, functions that work on concrete collections take the collection first and if appropriate return a collection of the same type. functions that take sequences (more accurately seqables) take the sequence last and return a seqable. cons is a seq function (takes seqable last) and always converts the last arg to a seq then adds the value to the front, returning a seq. conj is a collection function (takes coll first) and conjoins the new value(s) at the insertion point for the collection, which may be the beginning (lists), end (vectors, queues), or not meaningful for unordered colls (maps, sets). Returns the coll with the new values.

👍 2
phill15:07:04

Meanwhile, the name and argument-order of cons coincide with the Scheme tradition. So - besides the actual & usable information Alex provided - there may also have been a modicum of "happy coincidence" that made it seemly for the feature retain the name cons in Clojure.