If I understand your post correctly you feel that nil should
ONLY represent the concept of a missing value. It should not
represent false and empty.
Having used lisp in many different forms over the last 40 years
I think that the "complecting" of nil to represent all three
concepts is one of the most brilliant aspects of the language.
In fact it is one of the key flaws of scheme, in my opinion,
that they added true and false.
There is a fourth use of nil that is also very convenient.
Lisp functions return it as a default value. This makes it
possible to wrap functions with functions which other languages
like C++ make very difficult.
(e.g. if we have a C++ function
void foo()
we cannot wrap it with another
bar(foo())
well, we can but we have to use the comma hack as in
bar((foo(),1))
)
Java code is littered with checks for null before every
iterator construct where the code could be so much cleaner
if iterators just "did the right thing" with null, that is,
end the iteration.
The use of nil as a unified value for the many meanings leads
to a lot of useful features. The context of the nil value
completely defines the intended meaning.
Tim Daly
On Fri, 2011-10-21 at 09:50 -0700, Mark Engelberg wrote:
> I've always felt that Clojure's treatment of nil was somehow
> inconsistent with the elegance of many other features of Clojure. Now
> I can finally articulate why: nil complects non-existence, false, and
> empty.
>
>
>
> The choice to make nil represent so many concepts was an "easy"
> choice, because it saves a few characters when you can write things
> like (when seq ....) vs. (when (empty? seq) ...) and Clojure
> implements sequences in a way that the former expression is also a bit
> more performant. It is also easy in the sense that it is more similar
> to what Lisp users (as opposed to Scheme) are used to from past
> experience. But it is decidedly less simple to have these ideas
> complected.
>
>
> Over the past couple of years, I've seen numerous bugs along the lines
> of "Your function usually works great, but it breaks when the
> list/map/vector you pass in contains nil values." It seems clear to
> me that nil's complexity makes programs harder to analyze, because
> when you're writing your code, you might be thinking of nil as only
> representing non-existence or emptiness, for example, and forgetting
> that the system will treat nil as a false value as well.
> --
> 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
--
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
