There actually is a standardized value for "no value" in clojure: nil
The reason it's not useable as such in some places, is exactly it being
standardized.
Were we to introduce another such non-value, e.g. #<blackhole>, I think the
following would happen:
- people would be horribly confused on whether to use nil or #<blackhole>,
and rightfully so
- additional interop issues would be created, since you never know if you
have to expect nil, #<blackhole> or both
- it would help no one, since you still have to create custom values for
domain-specific nils, that have to be distinguishable from nil or
#<blackhole>
Effectively you are proposing a third 'falsey' value apart from false and
nil which would get us into the same mess as js with undefined vs null.
Except the stereotypical clojure dev would pull her hair out over this,
while the stereotypical js dev doesn't care and can't afford to, they even
have 0 == false and "" == false.
So the way to do it in clojure: ::undefined or a sentinel (Object.), if you
conceivably could get ::undefined in the data, like when processing your
own source code.
Remaining cases:
(f x) behaving differently from (f x nil): Just don't, even if it can be
done with arity overloading
(get {} :x) vs (get {:x nil} :x): to most code it should make no
difference. when it does, there is contains? or the not-found arg of get
That said, in CLJS we have adopted undefined as a third falsey value,
distinguishable from false and nil. I have no experience with problems
caused by reusing undefined as a domain specific nil, since I always treat
nil and undefined indifferently, so YMMV
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
