On Fri, 2011-10-21 at 12:36 -0700, Mark Engelberg wrote: > On Fri, Oct 21, 2011 at 11:43 AM, Mark Engelberg > <mark.engelb...@gmail.com> wrote: > >> How does nil represent empty? '() does not equal nil. > > > > (cons 1 nil) is one obvious example. > > > > The pattern of using first/next/nil? as a more efficient/compact > > alternative to first/rest/empty? is arguably another. > > > > One more anecdote about this. > > One time, I wrote a function that looked like this: > (defn f [s] > (when s .....)) > > At the time I wrote the function, I did the analysis, and realized > that my function was always being called with sequences (specifically, > sequences that had already been "seq-ified" at some prior point), so > it was safe to use "when" as a way to screen out the empty things. So > I opted for this easy, efficient way to express this. > > Somewhere along the line, as my application grew more complex, I > needed to reuse f in another context, and when looking at the docs for > f (which said something like "consumes a sequence and does ...", I > thought I could safely pass in a lazy sequence. But I couldn't > because when a lazy sequence is "empty" it is not "nil". My program > was buggy and it took a while track down the source of the problem.
THIS is where the multiple meaning of nil in traditional lisp is brilliant. I believe that Clojure "got it wrong" in the design decision to make (seq s) and (not (empty? s)) have different semantics. This is the same mindset that causes (me) so much grief in Java... looping and iteration does the wrong thing with NULL and I have to check for NULL every time. Yet everyone, if given an empty list of things to shop for, will know NOT to go shopping. > > Yes, it was my fault. In retrospect, I see that my program would have > been more robust had I not made assumptions about s, and written it as > (when (seq s) ...) > or perhaps > (when (not (empty? s)) ...) Actually I don't think this is entirely your fault (modulo the fact that we need to understand our language semantics). I believe that this is due to a deep design flaw. You're not the only person to mis-handle an empty sequence. > > But I do think it's fair to pin at least some of the blame on the > complexity of nil. Since nil can be used interchangeably with the > concept of emptiness in so many circumstances, and was interchangeable > in the initial context of my function, it was all too easy to rely on > that behavior. > Tim Daly Literate Software -- 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
