Just because we have dynamic types does not give us the freedom to not consider them.
(when s ...) Does not communicate anything about collections - only nil, false or something else. (when (seq s) ...) (when (empty? s) ...) Clearly express a consideration about the types at play. David On Fri, Oct 21, 2011 at 3:36 PM, Mark Engelberg <mark.engelb...@gmail.com>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. > > 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)) ...) > > 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. > > -- > 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
