>From quick & easy, to slower & more difficult, here are some options:
Use the functions you want in your own code, and find happiness in the fact that they are quick & easy to write. Make a library of this and perhaps other related functions on github. Perhaps also release JARs to clojars.org for other people to use. Post announcements of new versions to this list so more people learn about it. Add the functions you want to a Clojure contrib library. I don't know off-hand one that would be best for it, but perhaps creating a new one based off of the things that were in the "old" clojure.contrib.seq, perhaps with a name like clojure.contrib.seq, would be appropriate. If you want to see something like this in clojure.core, you can create a ticket on JIRA, preferably with a patch adding the new function as well as some unit tests, and then some day it may be screened and later included in Clojure's core code. For some of the reasons you have read in this thread, it might be rejected. http://clojure.org/patches has links to more info on the process. And, of course there is the option of trying to convince other people to do one of the above. That can be anywhere on the scale of amazingly quick & easy, to incredibly frustrating & hard, depending upon your ideas, how persuasive you are, and who reads your arguments. Andy On Jun 28, 2012, at 10:55 AM, Warren Lynn wrote: > Here is "another language" elisp: > > Anybody who use Emacs can do this: > > (subseq (make-vector 5 10) 2 4) => [10 10] > (subseq '(10 10 10 10 10) 2 4) => (10 10) > > As simple as that. Is that even worth the debate? :-) > > On Thursday, June 28, 2012 11:30:25 AM UTC-4, Warren Lynn wrote: > Some of my thoughts: > > 1. The argument that other languages do not have a similar thing is not > valid. If that is valid, we don't need Clojure in the first place. > > 2. The argument that other people did not raise the issue before and not > enough people support it so this is a non-issue is also not valid. If that is > valid, the vote-based committee designed language will be the best, and also > the most popular language will be the best. Of course, I do need people's > support so the change will happen, but that is different from the issue > itself. > > 3. Simplicity is defined as "constant time" operation is really weird here > to me. Simplicity in my view is a clear abstraction so conceptually things > behavior consistently, regardless the time. The user himself knows that > counting a sequence will take longer than vector, so it is his choice to use > vector of sequence. But counting is still counting, and he does not need to > have to choose between"countvec" or "countseq". That is what abstraction is > about. > > 4. Back to my original need. I need to use vector a lot because I deal with > large data set for numeric processing. When I extract a segment from the > vector, I still want it to be a vector. Of course it is doable even now (with > "vec" you can convert a sequence back to vector). But when I am writing some > basic routines, I don't want to limit them to vector as they may be useful > for sequence too. Still, I can write separate versions or with a lot of > conditions as someone else did. But are we trying to achieve something better > than doable here? > > 5. The solution is really simple. Add one or two functions as I suggested > before. I don't see any downside of that. > -- 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
