Hi, This will sound strange from me, but are these macros really to be added to the core?
Firstly, I don't see they extend the language in any way new. Instead they ease some very special cases, which could have been done with the combination of existing core functions/macros just as well, and that even might be more readable (as the confusion around naming and meaning suggests). It is a complexity. I would expect that everything in the core is important to know. If it turns out these new macros will not be used that much in real life (it doesn't matter if there are real life code where it COULD be used, what matters is that eventually will it GET used there), then it's just a burden for comprehending the core for any newcomer. Second, I have not seen myself using similar macros from other "contrib-like" libraries, neither writing similar stuff myself. I often feel the limitations of the parameter order of the "->" and "->>" macros, yes, but until we get feedback on the usage of such new macros, that they really get traction, I would feel worried about including them in the core name-space (for example in any reasonable project I find myself overriding "group-by"<https://groups.google.com/d/msg/clojure/pRla3_7vqvc/pqV1WwxjK4wJ>with a three parameter version). And thirdly, the "why" to my last sentence: because including them in the core namespace is a commitment. It should not be just removed later if it turns out no one really needs them. Should not be modified, or patched up, or prettified, or renamed later either. Because it can break someone's production code, someone's business, maybe someone's L.I.F.E. I'm not saying it CAN'T be changed, but it can reflect bad on us. There is no problem in saying "well, it turned out I was wrong, and now comes the hard work to get things right", but only if all the precautions were done beforehand. Why don't we have a "candidate" name-space, a separate library, like the contrib before, which most people who prefer to be on the cutting edge just include automatically. That would give reasonable feedback on how much traction new stuff like these get, and keeps it physically obvious what is considered The Core. Regards, Daniel On Friday, November 30, 2012 3:37:44 PM UTC, Rich Hickey wrote: > > I'm not satisfied with the names for the new threading macros either. > > The new names being considered for let->, test-> and when-> are: > > A) let-> becomes as-> > > reduces arg order and destructuring expectations. > > B) test-> becomes cond-> > > cond-> was the original name, and, protestations about not > short-circuiting like cond notwithstanding, it is still the best fit. The > doc string will say: > > "Note that, unlike cond branching, cond-> threading does > not short circuit after the first true test expression." > > C) when-> becomes some-> > > and in doing so, tests for non-nil rather than truth. > > ========== > This last one touches on the general area of non-nil-ness, often needed. > Other possible (future) ideas in line with this are: > > (some? x) == (not (nil? x)) > > (some coll) ;;note no pred, == (some some? coll) > > this is tricky, as we are bridging CL's some and Maybe's Some > > if-some, when-some et al. > > (some! x) ;;(or somex ?) identity for all but nil, which throws > > etc > ========== > > Last chance for fabulous and better names than these: (as->, cond-> and > some->). Note that "cond-> doesn't match cond's short-circuit" has been > considered already, please do not repeat. > > Thanks, > > Rich > > -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
