On 6 July 2010 22:02, Greg <g...@kinostudios.com> wrote: > Greg you're enthusiasm is appreciated. But this ML is filled with talented > and smart people who have an equal grasp of logic and reason who have been > using Clojure for a couple years now and they aren't clamoring to your nice > snippet of code. That's something to consider. > > It is indeed. I would be surprised though if I was the only person who sees > --> as useful, and that brings us to your next sentence... > > It is interesting that this is not the first time such a feature has been > requested. But again, I haven't ever had a need for such a general threading > macro. > > I'll make a list here of the reasons given for Yay/Nay so far: > Nay: > 1) "I haven't had a need for a general threading macro." > 2) The response so far is negative (and consists of repeating point #1 > above).
Sigh. I just *know* I shouldn't get involved in this... - It isn't particularly readable. (I know you disagree with this, but nevertheless, it has been stated as a negative point). - It is perfectly possible to write the macro yourself and use it in your own code. The fact that people haven't done this implies that it's less useful than you claim (you'll say I'm repeating (1) here, but never mind). - It is easy to emulate using the existing macros and anonymous functions like #(fn a % b). - The named variable can be omitted from a form. The implications of this are far from intuitive (and in the previous thread, there was even a suggestion that this should be treated as an error). > Yay: > 1) This has been requested multiple times. (Which pretty much cancels out > Nay #1 & #2). I think the statement was that it's been requested twice. Better than just once, but hardly "multiple"/ > 2) --> is a generalized version of -> and ->>, and therefore useful in > situations where you can't use -> or ->>. It is the 'nth' to 'first' & > 'last'. If you use anonymous functions, there are no such situations. It's a convenience rather than a generalisation. > 3) It makes code more readable by explicitly indicating where the argument > is passed. Your view. I find it very *un*readable. The first time I saw the let-> proposal, the named argument completely confused me. First, I misread the forms as expressions rather than templates, then I didn't follow the way the variable was (in effect) updated in each step. > At least if I've outlined the positions correctly, it's pretty sad that this > is being fought against so hard. You haven't. > I'll make the additional points that: > - There are plenty of macros and functions in the core that I'm sure you've > never used once, yet they are there for others who find them useful. So > simply responding to my proposal by saying, "I don't think I need it" isn't > a valid reason against its inclusion. Correct. The argument you are mischaracterising is that there is no evidence that an existing body of code (such as clojure core or clojure contrib) would benefit in any significant way from the proposal. Paul. -- 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
