On Nov 10, 2010, at 1:38 PM, Meikel Brandmeyer wrote: > Hi, > > Am 10.11.2010 um 17:37 schrieb Gary Poster: > >> But that's exactly my point. Why should developers have to remember to use >> rseq on a vector, as the first example? Why can't reverse simply be part of >> a protocol, so that it gives O(1) when it can? Is there *any* practical >> value to having reverse have O(n) performance on a vector? Clojure is >> advertised as a practical language (I remember reading it early in JoC, for >> instance), and I don't see it here. > > You got this backwards. There is nothing wrong with reverse being fast on > vectors.
Cool. > But it's promise is only O(n). In my opinion, its promise is that it reverses anything that supports the minimal seq interface. Its implementation can be pluggable via protocols, and we should be able to expect that the language provides reasonable implementations for its own data structures. (In fact, in Clojure, we should be able to expect that we can provide our own implementations for our own data structures.) > If you need fast reversal you have to use rseq. It makes your intention > explicit My intention to not be inefficient with a vector? That doesn't seem useful to me. My intention that I should be using a vector? If that's really important to me, then I can make some gesture to ensure it, I suppose, but I don't see that as being a reasonable common case. IMO, the reasonable common case for a practical language that is dynamically typed is that you take what you get and do your best with it. I think this--the idea that there is some value in being explicit that you expect a vector *by choosing these alternate vector-specific functions*--is the heart of our disagreement, as I highlight at the end. We seem to agree about most everything else. > and will protect you from someone passing in a seq or a list. rseq will bark > at you, while reverse silently decays your applications performance. Right, the "silently decaying" is my issue. It's not practical. It's giving a loaded gun to someone who cares about performance: "reverse" will always work, never complain, and silently and unnecessarily eat processing cycles if it is a vector. > Another point is: last, butlast, reverse are all functions from the seq > library. However there is a difference between seqs and datastructures. > Currently there is a clear distinction between functions acting on > datastructures and functions acting on seqs. And I think this is a good > thing. One has to clearly understand both worlds: A vector is not a seq. A > list happens to be its own seq. Not every seq is a list. Using the functions > for datastructures clearly states in which world you are currently walking. > As soon as you are in seq world you are in general bound to O(n). reverse > being fast on vectors is at best an implementation detail. AFAICT, the difference between datastructures and seq is that a seq is an interface, while data structures are concrete implementations. With a language that offers pluggable implementations for the interfaces, let's use that feature! > To be clear: I don't argue that reverse should be fast on vectors. I'm pretty sure that's "shouldn't" from context; please correct me otherwise. > Of course this would be a useful optimisation which basically comes for free. > I argue that removing the data structure functions with their performance > promises is a logical consequence of such an optimisation. I agree. As mentioned above, I think the primary (only?) point that we disagree on is that I think that this is a good thing (because it will simplify the number of things people need to know to use clojure, and get rid of a loaded gun for novices or even the unwary), and you don't (because you feel that this is a valuable way to constrain types, AIUI). Gary -- 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
