On Fri, Oct 21, 2011 at 12:41 PM, David Nolen <dnolen.li...@gmail.com> wrote: > Just because we have dynamic types does not give us the freedom to not > consider them.
Oh, I definitely considered the types when I wrote the function. It's just that at the time I wrote it, I was confident the input would already be seq-ified. nil, among its many purposes, is a key part of the "seq interface", and testing for nil is how you are expected to interact with seqs to determine emptiness. As my program grew, the assumption that the input would definitely be a seq was invalidated. This is exactly the inherent challenge of making evolving, maintainable programs that Rich speaks of in his video. If the only way to test for a seq to be empty were a general-purpose function like empty? that applied to all collections, my code would have worked in the new context. If the only to test for a seq to be empty were a seq-specific function like seq-empty? then when placed in the new context, my code would have broken in a very clear, easily diagnosable way. But because we test for seqs to be empty using nil, an object with many other purposes, my code appeared to work, but was semantically wrong -- always a hard thing to track down. I suppose one could also place some small portion of the blame on the problem of assigning clear linguistic labels to Clojure's types. Is something a sequence? A seq? A seqable? A collection? It's always been difficult to come up with clear definitions for these categories, and to specify the appropriate precondition with perfect clarity in a docstring. --Mark -- 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
