Maybe, (just maybe :-) what doesn't help Rich see the real interesting candidate to core (or the most probable candidates, those that just do one thing by filling a gap, such as spit) could be placed in a more visible namespace. For example, placing carefully designed general small additions such as spit in namespace clojure.contrib.core could facilitate the debates around the most probable incoming additions.
2009/5/13 Phil Hagelberg <p...@hagelb.org> > > > Now that Clojure 1.0 is out, I think it's a good time to take a look at > contrib. I noticed it didn't get an official 1.0 release along with > Clojure core. I wonder if this is because its role is just not very > well-defined. Several people have expressed this opinion here on the > mailing list and on IRC. > > My understanding is that contrib began as a "staging ground" for > core. If libraries or functions proved themselves useful, then they > could be promoted to core. > > I get the feeling that things have changed since then. For one, core > doesn't seem to grow that way any more. There was talk of moving some > functions from contrib to core way back in November, but that doesn't > seem to have gone anywhere. I understand there's good motivation to keep > core small, but perhaps it's time to rethink what contrib is for. > > The feeling I get now is that contrib is a bucket-o-code. Since we as a > community don't have any widely-accepted mechanisms for dependency > resolution, there's a quite understandable motivation to put useful > libraries in contrib so that other clojure hackers can make use of them > with minimal hassle. > > Right now if you want to handle nontrivial dependencies in your project, > you need to use Maven or Ivy. Many are reluctant to try these out since > they're perceived as heavy-weight, and the idea of writing executable > XML is rightfully viewed with suspicion by folks who're familiar with > Greenspun's Tenth Law; it's certainly tacky. But these tools have the > advantage that they work right now. > > I think things could be improved by creating a tool that wraps the > functionality that Maven provides in a more pleasant s-expression-based > interface and focuses just on the parts of Maven that are relevant to > building a Clojure project, but that's a discussion for another thread. > > I wonder if improving the dependency management story of Clojure will > help to clear up the confusion surrounding contrib. I certainly think > there's room for a "standard library" that ships with Clojure, and > precedent for this seems to be there with the existence of clojure.xml > and clojure.zip, but we need some discussion about why these libraries > are included and what others might also be worth including. > > It also may help to think about moving things out of contrib in two > ways: in one case functions would be moved into the core.clj namespace > (this was proposed of duck-streams' spit function) and in the other > whole libraries would get moved into the main Clojure distribution. It's > important to be very cautious with the first as these increase the > complexity of Clojure for everyone since they get loaded on startup, but > I suspect there's room for more growth in the second case. > > Would love to hear what folks think about this. > > thanks, > Phil > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
