On Thu, Jan 8, 2009 at 5:55 AM, Rich Hickey <richhic...@gmail.com> wrote: > When you > ask for the nth element/rest, you get the identical item every time.
I know this is nitpicking, but if this is really the promise that the seq abstraction is supposed to fulfill, then Clojure already violates this: (def a (seq [1 2 3])) (identical? (rest a) (rest a)) yields false Presumably what you mean is that the nth element should be identical (but not necessarily the nth rest). > The sequence abstraction in Clojure is the list abstraction of Lisp. > No more, no less. Well, in Lisp, lists are concrete, finite things that are mutable (and therefore don't provide any kind of guarantee that you'll get the same element with multiple traversals). So to say that Clojure's sequence abstraction is no more and no less than the list abstraction of Lisp is a bit misleading. You have a certain concept of what properties of this abstraction you want to model, and what promises you want to keep. And that's great -- honestly, I think it's fantastic that you have such a clear, coherent design vision that you've maintained throughout the creation of Clojure. I'm just saying that your interpretation of what constitutes an abstraction of a Lisp list is more subjective than your statement implies. I'm pretty sure my concept of the list abstraction differs from yours. In my mind the essential abstract concept of a list is anything that can be explained in this way: A list has a first and a rest, where first is some kind of element, and rest is another list or nil. In other words, I would say a sequence abstraction should apply to anything that has this sort of nested, self-referential recursive structure. There is an elegance to the way that algorithms on self-referential data structures can be expressed via recursion. To me, a big part of Clojure's beauty lies in the recognition that so many things can be converted to this view. Strictly speaking, a vector is not structured in this way, but you can convert it into something that has this property, allowing you to program vectors with this sort of recursive elegance. When I think about something like the sequence of whole numbers, it seems like a perfect embodiment of what I consider to be the essential abstraction of a sequence. You've got a first thing, and the rest thing is another sequence that has similarity to the original. Because it has a recursive structure, I want to be able to operate on it using first and rest. To me, a sequence feels like the "right abstraction" for the whole numbers, and writing algorithms that operate on them. And this feels like the right abstraction to me regardless of implementation details such as whether the traversed numbers should reside in memory all at once. > Making seqs 'non-caching' makes no sense because they are no longer > the same abstraction. I get that your design vision revolves around the idea that sequences promise identity, and that there are real technical challenges surrounding the idea of non-cached sequences. But I don't consider "non-caching sequences" to be an oxymoron. If it were possible to implement them in a way that meshed with the rest of Clojure's design, I think there would be real value to being able to manipulate non-cached recursive structures with the existing sequence interface. It's clear you don't think this fits with Clojure's design, but I haven't yet given up hope of finding a clever way to do this, and trying to convince you that it is worthwhile :) . I know that over email, it is all too common for the tone of a post to be misconstrued. So just in case, I want to emphasize here that these posts are in no way intended as bashing Clojure or Rich's design sensibilities. It is precisely because I admire the design, and already care about Clojure, that I raise these points in the hope that community discussion can elevate the language even further. I strive to make my comments as constructive in tone as possible, and I hope that they are perceived in that light. --~--~---------~--~----~------------~-------~--~----~ 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 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 -~----------~----~----~----~------~----~------~--~---
