> As a Lisp newcomer (your trailing parens give you away) I'm a newcomer to Clojure, not Lisp. I trail my parens because I think it results in more readable code, and I'm pretty sure I have good reasons for thinking so. They will continue to be trailed, and don't bother trying to suggest otherwise, unless you're interested in hearing me convince you of how wrong you are. :-)
> At a glance, people will presume that prints the same thing twice > [..] > _ is an input, then a result. Why give it the same name? Now *that's* a reasonable and rational argument against including -->. :-) I will point out though, that if you were to just read the code for -> or ->>, they would also seem counterintuitive until you read the documentation. They do not follow any standard Lisp calling convention, it is something that must be understood by reading the docs, and therefore the same applies to -->. Anyone encountering it would have to read the docs to understand it. Once they read it, I think it becomes intuitive. Again, even The Joy of Clojure points out that people use commas with -> and ->> to indicate the location of the parameter. This is no different, except it actually works. > In short, this and its variants are not going to get into Clojure :-\ Thanks for making that clear though, as now people can point others to response when it comes up again. > Please be courteous and let it rest. That's my plan, and I think I've done my best to give the same level of courtesy to others as that I've received. - Greg On Jul 6, 2010, at 6:17 PM, Rich Hickey wrote: > On Jul 6, 2010, at 5:24 PM, Greg wrote: > >>> This would be most likely java interop, ie. ->. >>> There the main arguments are 99% of the times the first or the last ones. >>> So -> or ->> will work >> >> OK, so what happens when one of the functions takes it in the front, and the >> other in the back? >> >> Or what happens when you're using a piece of code that doesn't follow either >> convention? Are you saying such code doesn't exist? >> >> In both those cases, -> and ->> become useless. >> > > They simply don't apply. It's not as if nails make screwdrivers useless. > > As others have said, this has come up before and been rejected. You'd do well > to heed what other people are saying. As a Lisp newcomer (your trailing > parens give you away), you might presume they have more experience (though > that doesn't make them inherently right). > > Your assumption that because it has been asked for before it is therefore > needed is not correct. People ask for things all the time that they don't > need. Often people suggest things as a thought exercise: "what's the > generalization of -> ?" > > -> and ->> are simplifications for consistent usages (target value and > sequences respectively). Many functions follow those conventions. When they > don't, or the operations are mixed, it's time to be more explicit, not to > come up with a trickier shorthand. > > The bottom line is that --> and let-> are not good ideas, because they mess > up lexical naming badly. Setting aside that _ is idiomatic for "don't care", > consider the counterintuitive behavior of: > > (--> 3 (prn _) (prn _)) > > At a glance, people will presume that prints the same thing twice. The name > _ is taking on different values with no intervening binding form or > recursion. And anything like let-> that allowed you to name the arg has the > same problem. There is no good name, as the semantics of the parameter often > change with each invocation. I.e. in your original example: > > (--> 3 (+ 1 _ 4) (prn "answer:" _)) > > _ is an input, then a result. Why give it the same name? > > (--> 3 (+ 1 _ 4) (prn "answer:" _)) is not better than: > > (let [x 3 a (+ 1 x 4)] (prn "answer:" a)) > > and in the latter case you'd never give x and a the same name, never mind _. > > In short, this and its variants are not going to get into Clojure. Please be > courteous and let it rest. > > Thanks, > > Rich > >> >> On Jul 6, 2010, at 5:20 PM, Meikel Brandmeyer wrote: >> >>> Hi, >>> >>> Am 06.07.2010 um 20:09 schrieb Greg: >>> >>>> On Jul 6, 2010, at 2:01 PM, Stuart Halloway wrote: >>>> >>>>> (1) Clojure APIs are very careful about parameter order. >>>> >>>> And what if you want to use a function outside of the Clojure API? >>> >>> This would be most likely java interop, ie. ->. >>> >>>> Or a function *in* the Clojure API that doesn't follow the parameter order >>>> you want? >>> >>> There the main arguments are 99% of the times the first or the last ones. >>> So -> or ->> will work. >>> >>>>> (2) -> and ->> encourage chains of operations that build on that >>>>> parameter order. >>>> >>>> Why is that important? >>> >>> Because consistency matters. >>> >>>>> (3) I haven't seen a lot of examples where something like --> solves real >>>>> problems in code. >>>> >>>> I haven't coded long enough in Clojure to provide you with any examples, >>>> but it seems like hoping that the functions you're going to use are going >>>> to have the correct parameter order is silly. Why hope when you can >>>> guarantee it won't matter? >>>> >>>> Anyways, you haven't seen a lot of examples simply because people don't >>>> have a --> to use. Thus they're are forced to work around it, for example >>>> by replacing calls to -> or ->> with the corresponding standard calls >>>> (postfix/prefix? don't remember what that style is called). >>>> >>>> If it existed, you would see it being used. >>> >>> I don't think so. For example sequence or not-empty exist. But I never >>> needed one of them in two and half years of Clojure coding. And I can't >>> remember to have seen a single usage in other peoples code. (of course an >>> absolutely representative sample... ;)) >>> >>>> Yes, let's handicap ourselves and then disparage a useful macro as >>>> "unneeded." The -> and ->> macros aren't needed either, so why are they >>>> there? While we're at it, we should make it so that the + function takes >>>> only two arguments because any more leads to "unneeded versatility" and >>>> therefore, apparently, to "support headache." :-p >>> >>> Can we tune down the rethoric a little bit? These issues were discussed in >>> depth several times now. And the fact that such a macro was not included in >>> core should give a hint, that the pain can't be that big. >>> >>> Sincerely >>> Meikel >>> >>> > > -- > 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
