morning

I find this weird as I continue my Clojure journey.

maws.core> (if [] (print "Hello"))
Hello
nil
maws.core> (if nil (print "Hello"))
nil

The empty list is not nil and not false? Yet nil can be used in place of an empty seq, list, map. So nil = [] but [] != nil Equality is no longer commutative.

Just seems wrong somehow.

Well for actual clojure equalities it’s always false so at that level it is commutative.

maws.core> (= nil [])
false
maws.core> (= [] nil)
false
maws.core> (:matt nil)
nil
maws.core> (:matt {})
nil

Up to the point I can switch nil in for an empty map. But I can’t swap in an empty map for a condition.

I guess people write not-empty everywhere in conditions?

Oh well 🙂

if what you're asking were true what'd follow would be that () = [] = {} = nil which is clearly nonsensical

yes that’s the point

nil is all those things in certain contexts

but those things are not nil and not false in conditionals (like in other lisps)

A vector is a vector, which just happens to be empty.

@mattford no, nil is not the empty list/vector/map in any context. some functions will coerce nil to either one of those but it doesn't imply equality

(nil :matt)

that's a NPE, nil is not an IFn, what's surprising about that?

Isn’t nil in that context an empty map?

no

why would it be?

nil is always just nil

it acts exactly like one

no it doesn't

user=> (:foo 123)
nil

it just so happens that get will return nil if trying to access elements from a non associative data structure

doesn't mean that anything that get returns nil from is a map

I was reading this which I guess is misleading.

http://www.lispcast.com/nil-punning

it's garbage in garbage out

@mattford the distinction you have to understand is that nil isn't or doesn't behave like an empty collection in some contexts, some functions decide to return the same result when invoked on nil as they do if invoked on an empty collection but that's up to the specific function

ah

e.g. if you have a function that acts on maps and you pass nil, it's likely that (f nil) will produce the same result as (f {})

but that's up to the implementation of f

gotch ya

Seems a bit dangerous no?

not really

after getting used to writing clojure you'll realize it really isn't an issue

That explanation is a big help 🙂

btw that blog post says because nil is a seq which is not really accurate

yeah - misleading

altho it's true that almost all functions that operate on seqs, behave on nil as if they were acting on ()

except when they don’t 😉

well to be fair i can't think of any sequence function right now that doesn't operates differently on nil than it does on empty seqs

(in clojure the concept of a sequence is different from the more general concept of a collection)

I started on this road by using cond and assuming the empty list,seq, map would be false.

no values in clojure other than false and nil are considered falsey

Yep - but I noticed that nil (mostly) worked as the empty list and couldn’t understand how that would work. Until you explained.

fair enough

i guess if you come from other lisps this might be a bit confusing :)

🙂

There’s a table here and some further interesting discussion in the links http://stackoverflow.com/questions/5830571/why-did-father-of-clojure-say-that-schemes-true-false-are-broken

@mattford does it help to consider that (seq []), (seq '()), (seq {}), and (seq nil) all produce nil -- and all sequence functions start by call seq on their argument to handle an empty sequence. This makes it much easier to compose sequence functions since you don't have to worry about nil -- it will just pass through safely.

a bit 🙂

Say I’m collecting the results of a bunch of functions in a vector, they return nil if they don’t do anything. Normally I’d just flatten it.

But as I have a whole load of nils that doesn’t work.

flatten is rarely what you want

(mapcat identity your-coll) usually is enough

That breaks down my strings also - hows about (keep identity collection)

@mattford You can drive boot from the REPL, don’t think you can with Leiningen.