I love the -> and ->> macros, but the problem with them is that you're limited to the functions you can use. Either all of the functions must be functions where the argument is passed as the first argument, or they must all be functions where it's passed in at the end.
I'm making my way through the Joy of Clojure right now, and it mentions that some people actually use commas to sort of "hint" as to where the argument will go (with the -> and ->> macros). Why not then just use a macro that actually listens to your hints?
So I whipped out this --> macro that does just that:
So why hasn't it been incorporated yet into the standard library?
The --> macro (or the let-> mentioned there) is more powerful than -> and ->>, and it also makes code more readable too. It seems strange therefore not to have one.
> Note, that you can ease your pain a little with #(): (-> 3 (#(+ 1 % > 4)) (#(prn "answer:" %))). This is rather ugly, though.
> 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+unsubscribe@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en
> So why hasn't it been incorporated yet into the standard library?
> The --> macro (or the let-> mentioned there) is more powerful than -> and ->>, and it also makes code more readable too. It seems strange therefore not to have one.
> - Greg
>> Note, that you can ease your pain a little with #(): (-> 3 (#(+ 1 % >> 4)) (#(prn "answer:" %))). This is rather ugly, though.
>> 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+unsubscribe@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+unsubscribe@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en
Maybe there is just not much need for such a macro (at least for me,
don't for the generality of users). 99% of my use cases can be handled
with -> or ->> (or a combination there of).
>> So why hasn't it been incorporated yet into the standard library?
>> The --> macro (or the let-> mentioned there) is more powerful than -> and ->>, and it also makes code more readable too. It seems strange therefore not to have one.
>> - Greg
>>> Note, that you can ease your pain a little with #(): (-> 3 (#(+ 1 % >>> 4)) (#(prn "answer:" %))). This is rather ugly, though.
>>> 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+unsubscribe@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+unsubscribe@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+unsubscribe@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en
(1) Clojure APIs are very careful about parameter order. (2) -> and ->> encourage chains of operations that build on that parameter order. (3) I haven't seen a lot of examples where something like --> solves real problems in code.
In my experience, unneeded versatility == support headache.
> On Jul 6, 2010, at 11:47 AM, Stuart Halloway wrote:
>> There is not general agreement that something like --> is more readable. (I for one disagree, at least so far.)
> I'm very curious as to why as I find it hard to even fathom how you could think it's less readable to be explicit about the location of the parameter.
> Still, that doesn't change two facts:
> 1) I, and many others, find -> and ->> *less* readable because they do not indicate at all where the parameter is.
> 2) --> is more versatile than either -> and ->>.
> So why keep it out of the core library?
> - Greg
>> Stu
>>> On Jul 6, 2010, at 8:23 AM, Meikel Brandmeyer wrote:
>>> So why hasn't it been incorporated yet into the standard library?
>>> The --> macro (or the let-> mentioned there) is more powerful than -> and ->>, and it also makes code more readable too. It seems strange therefore not to have one.
>>> - Greg
>>>> Note, that you can ease your pain a little with #(): (-> 3 (#(+ 1 % >>>> 4)) (#(prn "answer:" %))). This is rather ugly, though.
>>>> 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+unsubscribe@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+unsubscribe@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+unsubscribe@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+unsubscribe@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en
> Maybe there is just not much need for such a macro (at least for me, > don't for the generality of users). 99% of my use cases can be handled > with -> or ->> (or a combination there of).
> 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+unsubscribe@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en
> It now requires an additional replace-all function (a modified replace):
Oops! No it doesn't. That's from earlier experimentation that I did, and it's not necessary at all with the latest version (you'll see the --> macro doesn't even call it. :-p
>> Maybe there is just not much need for such a macro (at least for me, >> don't for the generality of users). 99% of my use cases can be handled >> with -> or ->> (or a combination there of).
>> 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+unsubscribe@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en
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? Or a function *in* the Clojure API that doesn't follow the parameter order you want?
> (2) -> and ->> encourage chains of operations that build on that parameter order.
Why is that important?
> (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).
> In my experience, unneeded versatility == support headache.
> Stu
>> On Jul 6, 2010, at 11:47 AM, Stuart Halloway wrote:
>>> There is not general agreement that something like --> is more readable. (I for one disagree, at least so far.)
>> I'm very curious as to why as I find it hard to even fathom how you could think it's less readable to be explicit about the location of the parameter.
>> Still, that doesn't change two facts:
>> 1) I, and many others, find -> and ->> *less* readable because they do not indicate at all where the parameter is.
>> 2) --> is more versatile than either -> and ->>.
>> So why keep it out of the core library?
>> - Greg
>>> Stu
>>>> On Jul 6, 2010, at 8:23 AM, Meikel Brandmeyer wrote:
>>>> So why hasn't it been incorporated yet into the standard library?
>>>> The --> macro (or the let-> mentioned there) is more powerful than -> and ->>, and it also makes code more readable too. It seems strange therefore not to have one.
>>>> - Greg
>>>>> Note, that you can ease your pain a little with #(): (-> 3 (#(+ 1 % >>>>> 4)) (#(prn "answer:" %))). This is rather ugly, though.
>>>>> 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+unsubscribe@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+unsubscribe@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+unsubscribe@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+unsubscribe@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+unsubscribe@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en
On Jul 6, 2010, at 2:26 PM, Wilson MacGyver wrote:
> On Tue, Jul 6, 2010 at 2:01 PM, Stuart Halloway > <stuart.hallo...@gmail.com> wrote: >> In my experience, unneeded versatility == support headache.
> I couldn't agree more. I'm happy to see selection of what goes into > core and contrib has become more selective.
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
> -- > 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+unsubscribe@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en
On Tue, Jul 6, 2010 at 2:36 PM, Greg <g...@kinostudios.com> wrote: > On Jul 6, 2010, at 2:26 PM, Wilson MacGyver wrote:
> > On Tue, Jul 6, 2010 at 2:01 PM, Stuart Halloway > > <stuart.hallo...@gmail.com> wrote: > >> In my experience, unneeded versatility == support headache.
> > I couldn't agree more. I'm happy to see selection of what goes into > > core and contrib has become more selective.
> Yes, let's handicap ourselves and then disparage a useful macro as > "unneeded."
What handicap? You wrote a macro that works for you that you can use in your own code. Aren't macros great? :)
> The -> and ->> macros aren't needed either, so why are they there?
I've found a real need for -> ->>. I haven't personally felt a strong desire for --> ... yet.
> 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
> - Greg
Now you're just getting contentious ;)
On a style note, you should follow the Lisp convention on the location of closing parens.
On Tue, Jul 6, 2010 at 2:36 PM, Greg <g...@kinostudios.com> wrote: > On Jul 6, 2010, at 2:26 PM, Wilson MacGyver wrote:
>> On Tue, Jul 6, 2010 at 2:01 PM, Stuart Halloway >> <stuart.hallo...@gmail.com> wrote: >>> In my experience, unneeded versatility == support headache.
>> I couldn't agree more. I'm happy to see selection of what goes into >> core and contrib has become more selective.
> 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
You know, just because you wrote a macro that you love and it works for you, doesn't mean it should get into clojure.core :)
Greg <g...@kinostudios.com> wrote: > On Jul 6, 2010, at 2:01 PM, Stuart Halloway wrote: > > (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.
If that's true, then it should be easy to find places in either clojure.contrib or the parts of clojure.core that are written in clojure that could make use of it.
> On Jul 6, 2010, at 2:26 PM, Wilson MacGyver wrote:
> > On Tue, Jul 6, 2010 at 2:01 PM, Stuart Halloway
> > <stuart.hallo...@gmail.com> wrote:
> >> In my experience, unneeded versatility == support headache.
> > I couldn't agree more. I'm happy to see selection of what goes into
> > core and contrib has become more selective.
> 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
> - Greg
> > --
> > Omnem crede diem tibi diluxisse supremum.
> > --
> > 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+unsubscribe@googlegroups.com
> > For more options, visit this group at
> >http://groups.google.com/group/clojure?hl=en
> You know, just because you wrote a macro that you love and it works > for you, doesn't mean it should get into clojure.core :)
I agree 100%, which is why I've explained the reasons for the suggestion.
I did not simply say "OMG I made this awesome macro now include it!"
I gave explicit reasons on *why* it should be included and defended them rationally. The responses I've received so far in opposition have been devoid of any real substance other than, "I don't want to."
The -> and ->> macros are like the 'first' and 'last' functions.
It would be silly to have a Clojure with only 'first' and 'last' functions, and without an 'nth' function.
The --> macro is the 'nth' equivalent.
It is a generalized version of the -> and ->> macros, able to handle situations they can't, and it happens to also have the added benefit of more readable code.
Therefore I think it should be in the core.
- Greg
On Jul 6, 2010, at 4:04 PM, Wilson MacGyver wrote:
> On Tue, Jul 6, 2010 at 2:36 PM, Greg <g...@kinostudios.com> wrote: >> On Jul 6, 2010, at 2:26 PM, Wilson MacGyver wrote:
>>> On Tue, Jul 6, 2010 at 2:01 PM, Stuart Halloway >>> <stuart.hallo...@gmail.com> wrote: >>>> In my experience, unneeded versatility == support headache.
>>> I couldn't agree more. I'm happy to see selection of what goes into >>> core and contrib has become more selective.
>> 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
> You know, just because you wrote a macro that you love and it works > for you, doesn't > mean it should get into clojure.core :)
> -- > Omnem crede diem tibi diluxisse supremum.
> -- > 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+unsubscribe@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en
No, sorry, I think that's a rather unreasonable request. I'm not going to spend hours sifting through the core and contrib just to jerk out examples for you.
> On Tue, 6 Jul 2010 14:09:18 -0400 > Greg <g...@kinostudios.com> wrote: >> On Jul 6, 2010, at 2:01 PM, Stuart Halloway wrote: >>> (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.
> If that's true, then it should be easy to find places in either > clojure.contrib or the parts of clojure.core that are written in > clojure that could make use of it.
> -- > 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+unsubscribe@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en
> No, sorry, I think that's a rather unreasonable request. I'm not going to spend hours sifting through the core and contrib just to jerk out examples for you.
> I'd rather use logic and reason to make my case.
It's not unreasonable when you are arguing (rather vehemently) for its inclusion in clojure.core, for which there is a high bar. And logic alone isn't likely to be able to answer the question of whether enough people would use this macro to make its inclusion worthwhile.
> No, sorry, I think that's a rather unreasonable request. I'm not going to spend hours sifting through the core and contrib just to jerk out examples for you.
> I'd rather use logic and reason to make my case.
I don't think that this was intended to be unreasonable. I believe the motivation here is to help everyone understand the basis for your idea with a concrete example. No one would want you to spend hours sifting through code to prove a point. I would just start with a few reasonable places and see if you can code up a quick example. I believe that this is a fair request. I would very much like to see some specific examples as it would help solidify your ideas.
>>> On Jul 6, 2010, at 2:01 PM, Stuart Halloway wrote:
>>>> (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.
>> If that's true, then it should be easy to find places in either >> clojure.contrib or the parts of clojure.core that are written in >> clojure that could make use of it.
>> Have you checked for those?
>> <mike >> -- >> Mike Meyer<m...@mired.org> http://www.mired.org/consulting.html >> Independent Network/Unix/Perforce consultant, email for more information.
>> -- >> 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+unsubscribe@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en
On Tue, Jul 6, 2010 at 4:16 PM, Greg <g...@kinostudios.com> wrote: > > Have you checked for those?
> No, sorry, I think that's a rather unreasonable request. I'm not going to > spend hours sifting through the core and contrib just to jerk out examples > for you.
> I'd rather use logic and reason to make my case.
> - Greg
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 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.
One nice side effect of -> and ->> over --> is that it encourages everyone to consider the position of their arguments. Uniformity is nice.
Greg <g...@kinostudios.com> wrote: > > Have you checked for those?
> No, sorry, I think that's a rather unreasonable request. I'm not going to spend hours sifting through the core and contrib just to jerk out examples for you.
> I'd rather use logic and reason to make my case.
The examples aren't for me, they're for *you*. They provide evidence to back up the assumptions your logic and reason start from. To wit: you claim that there's a lot of need for this type of macro. Others disagree with that claim. This isn't a claim that logic or reason can prove. Without some kind of hard evidence, whether it's true or not is basically a shouting match. The best place to get hard evidence is clojure.contrib and clojure.core.
> 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).
Yay:
1) This has been requested multiple times. (Which pretty much cancels out Nay #1 & #2). 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'. 3) It makes code more readable by explicitly indicating where the argument is passed.
At least if I've outlined the positions correctly, it's pretty sad that this is being fought against so hard.
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.
- Most of you have used the other threading macros (-> and ->>), so you do in fact encounter situations and examples where the --> macro could be used. If it existed in the core already I think there's a pretty good chance you would have even used it yourselves, and your code would then gain the added benefit of being more readable.
As you pointed out earlier though, macros are great, and I'm free to use this macro in my own code, so I will.
> On Tue, Jul 6, 2010 at 4:16 PM, Greg <g...@kinostudios.com> wrote: > > Have you checked for those?
> No, sorry, I think that's a rather unreasonable request. I'm not going to spend hours sifting through the core and contrib just to jerk out examples for you.
> I'd rather use logic and reason to make my case.
> - Greg
> 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 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.
> One nice side effect of -> and ->> over --> is that it encourages everyone to consider the position of their arguments. Uniformity is nice.
> David
> -- > 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+unsubscribe@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en
> 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.
On Tue, Jul 6, 2010 at 5:02 PM, Greg <g...@kinostudios.com> wrote:
> 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).
3) It would encourage people to not follow Clojure's conventions around argument positions for fns that deal with sequences/collections.
That is a pretty important Nay and illustrates that --> decreases readability for people that have spent time with Clojure.
It also points out why -> and ->> are not really about position anyway, it's about threading an expression. -> is to make Clojure read left-right instead of inside-out. ->> is to make Clojure read left-right when operating on sequences/collections.
Both are far, far more common and useful then being able to fill arguments anywhere.
