Thanks for clarifying more on the rationale behind the design. Also a note on the tone: I never thought insisting on a view is offensive. Insisting our views are the essence of a debate. But we need to insist based on reasons and acknowledge when we are wrong. Also, I realize that sometimes debating on a forum is different from face-to-face debating and offense is easier to make. I hope nobody took any offense.
Here actually I am not only trying to ask for a faster "last". I am trying to understand some of the designs here (and along the way insisting on my own "right" one), because I have this regretful feeling that Clojure has some really nice LISP features but failed on some basic stuff, and I am seriously doubting whether I should invest more on it (possibly on a production system). I will be more than glad to be convinced that the design is sound, but I will need enlightenment. My understanding here is "ISeq" is an INTERNAL, implementation level interface/abstraction, not the user/language level abstraction (which in this case should be "ordered collection", as somebody called), so whether "last" is part of "ISeq" is irrelevant. In my view, at the user/language level, last should work on all ordered collections as fast as it can without EXPOSING whatever internal implementation is on. I know there is a lot of exciting projects going on with Clojure. But a good review of the design does not conflict with that, and may be beneficial for future exciting projects. I am still insisting on my view, but I hope its based on reasons. On Friday, June 29, 2012 2:45:53 PM UTC-4, Nicolas wrote: > > I would say we can have different ways of designing things. > > A way is to design abstractions and provide services on top on theses > abstractions. The abstraction here is ISeq. That is sequences. Last > is not part of the ISeq abstraction and just work on top of it. There > is no way to access last element directly from something that is just > a an ISeq. So last can't use it. > > If last was part of ISeq abstraction, you would not need a separate > last function at all. But this would also mean that all ISeq > implementations would need to implement last. This would be sure > conveniant, but this is not the same abstraction. It is also heavier > (more code, more maintenance...). And for some implementation like > networks streams, this would be anoying than anything as it would > provide no added value. > > Seq abstraction is exactly that: a very basic (yet powerfull) > abstraction for accessing streams, linked list and other specialized > structures that are sequential in essence. > > Clojure team could have designed last to work on any possible type > where it make sense and so have better performance for each possible > type. An efficient implementation would use a protocol to do so. > Making last its own abstraction. This is indeed possible, but was not > the choice here. > > Fact is others abstractions already allow you to have the last element > directly like Indexed if this important to you. > > So yes we could have a better last, promoting it to a full > abstraction. Like clojure could be many more things. Is this REALLY a > priority for the future of clojure? Not at least for clojure core > team. I tend to share their views. You have the right to disagree. > > On my side, I'am far more interrested to see progress in > clojurescript, IDEs, tooling, maybe even grid computing. > > You care about last. This is your right... And well why not implement > your own last in contrib or private lib and use if it is important? > Like other members of the community implemented code matching their > own interrest. > > It is logical you ask for it, but there is no need to insist or maybe > be a little offensive if others don't share your views. > > Regards, > > Nicolas Bousquet. > > On 29 juin, 01:32, Warren Lynn <wrn.l...@gmail.com> wrote: > > This is an off-shoot subject from my last post "General subsequence > > function". > > > > I found people had similar questions before (one year ago): > http://groups.google.com/group/clojure/browse_thread/thread/712711f04... > > > > As of Clojure 1.4, seems nothing changed, as "source" show here: > > > > user> (source last) > > (def > > ^{:arglists '([coll]) > > :doc "Return the last item in coll, in linear time" > > :added "1.0" > > :static true} > > last (fn ^:static last [s] > > (if (next s) > > (recur (next s)) > > (first s)))) > > > > Any reason for that? Thanks. -- 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
