Getting code into a Clojure contrib library, or into clojure.core, require convincing others that maintain the appropriate namespace.
One way to be persuasive is to make a library of useful code on github and clojars.org, advertise it here, and have folks try it out. If they do, and like what they find, you could build a groundswell of support for the field-tested code, which might later then be copied into a contrib library or core. It is also easier to iterate on changes to the behavior of the code, documentation strings, etc. with a github repo under your control, versus one that requires convincing others for every single change. There are widely-used libraries that are neither in core nor contrib, e.g. Ring, Compojure, Noir, Pallet, Seesaw, etc. Their creators get to make changes to them whenever they wish, although I think they tend to become very cautious about making backwards-incompatible changes as they become more widely used. Andy On Jun 28, 2012, at 12:47 PM, Warren Lynn wrote: > Andy: > > Thanks for laying out the options to move it forward. I think those functions > belong to clojure.core, but I will see how persuasive I am, or how receptive > the community is. :-) > > On Thursday, June 28, 2012 2:53:27 PM UTC-4, Andy Fingerhut wrote: > 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 -- 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
