On Friday, July 19, 2013 7:18:15 AM UTC-7, Daniel Dinnyes wrote:
>
> You are trying to pick it up on the wrong end. Check this out:
>
> (-> "test-string-with-lots-of-dashes"
> (fn [x] (s/split x #"-"))
> (fn [y] (interleave y (range)))
> (fn [z] (s/join #"_" z))
> (fn [z] (s/join
> I understood David's comment differently, that the current threading
> macros exist so that explicit bindings for each threaded form are not
> needed for they very specific cases they intend to simplify. I'm not saying
> your macro is dumb, I just don't find the sugar particularly tasty. ;-)
On July 19, 2013 at 11:28:50 AM, Daniel Dinnyes (dinny...@gmail.com) wrote:
Oh, and the implementation is clean and simple. Just cleaned it up a bit from
all the clutter:
;;; The DUH..IT'S SO SIMPLE! macro
(defmacro duh->
([x alias form]
`(let [~alias ~x] ~form))
([x alias form & more]
Oh, and the implementation is clean and simple. Just cleaned it up a bit
from all the clutter:
;;; The DUH..IT'S SO SIMPLE! macro
(defmacro duh->
([x alias form]
`(let [~alias ~x] ~form))
([x alias form & more]
`(duh-> (duh-> ~x ~alias ~form) ~@more)))
This gives YOU the full power
Cheers mate, good point there!
On Wednesday, July 17, 2013 6:03:41 PM UTC+1, David Nolen wrote:
>
> While the macro can do what the original enhancement request suggested
> that's not the actual problem the new threading macros were intended to
> solve. They were primarily added to eliminate:
>
On Monday, July 15, 2013 11:53:09 PM UTC+1, Jeremy Heiler wrote:
>
> On July 15, 2013 at 6:30:28 PM, Daniel Dinnyes
> (dinn...@gmail.com)
> wrote:
>
> Hmm, good point, especially the `let` one... What is `as->`? I can't find
> anything about that.
>
> http://clojure.github.io/clojure/clojure.c
See this discussion: https://groups.google.com/forum/#!topic/clojure/67JQ7xSUOM4
(kinda hard to Google for functions with -> in their name so it took
me a bit of digging!)
Sean
On Wed, Jul 17, 2013 at 10:15 AM, Steven Degutis wrote:
> In that case, shouldn't it be named let-> instead of as->?
>
Thank you for the explanation, it makes sense to me now.
On Wednesday, July 17, 2013 8:03:41 PM UTC+3, David Nolen wrote:
>
> While the macro can do what the original enhancement request suggested
> that's not the actual problem the new threading macros were intended to
> solve. They were primar
In that case, shouldn't it be named let-> instead of as->?
On Wed, Jul 17, 2013 at 12:03 PM, David Nolen wrote:
> While the macro can do what the original enhancement request suggested
> that's not the actual problem the new threading macros were intended to
> solve. They were primarily added to
While the macro can do what the original enhancement request suggested
that's not the actual problem the new threading macros were intended to
solve. They were primarily added to eliminate:
(let [x ...
x ...
x ...]
...)
Which is pretty ugly and also it's pretty easy to get into tro
I'm sorry for jumping in then. Should have paid more attention to the dates.
Nevertheless I wonder why while standing on such a solid ground, the Core
team eventually gave in. I could see a use for cond->, but as-> is
basically the same macro that was suggested in topics like this, and was
reje
Note the original discussion was from 2010.
On Wed, Jul 17, 2013 at 11:49 AM, Alexander Yakushev wrote:
> What a twist.
>
> Does any of the participants care to comment on this one? A hundred posts
> of bashing a person from the position of authority while the macro in
> question already sits in
What a twist.
Does any of the participants care to comment on this one? A hundred posts
of bashing a person from the position of authority while the macro in
question already sits in Core. I am against the usage of it myself, and
closely followed previous discussions on this topic to understand
Ugh. What a pointless thread. Someone could have just said:
---
It's already in clojure 1.5. The form you are looking for is called as->.
Your original example would be written like this:
(as-> 3 x (+ 1 x 4) (prn "answer:" x))
---
Done. Yeesh.
On Sunday, July 14, 2013 12:34:02 PM UTC-4,
On July 15, 2013 at 6:30:28 PM, Daniel Dinnyes (dinny...@gmail.com) wrote:
Hmm, good point, especially the `let` one... What is `as->`? I can't find
anything about that.
http://clojure.github.io/clojure/clojure.core-api.html#clojure.core/as-%3E
There is one benefit over `let` though: it is more e
Hmm, good point, especially the `let` one... What is `as->`? I can't find
anything about that.
There is one benefit over `let` though: it is more explicit. Let allows you
to define independent bindings mixed together with multiple threads of
dependent bindings (which can be mixed in random comb
On Sat, Jul 13, 2013 at 10:49 PM, Daniel Dinnyes wrote:
> (->>> "test-string-with-lots-of-dashes"
> x (s/split x #"-")
> y (interleave y (range))
> z (s/join #"_" z)
> z (s/join " * " ["I am serious" z "Not Kidding!!" z]))
Why not use as-> or a let in this situatio
On Sat, Jul 13, 2013 at 9:08 PM, Daniel Dinnyes wrote:
> Just made a quick search on `main arguments` on both Google and Wikipedia.
> Do you mean the arguments in `public static void main (String[] args)`? If
> not please provide some definition what do you mean by main arguments. Else
> the point
Hey guys, I just came up with some good shit, check this out!
(defmacro ->>>
([x] x)
([x alias form]
`(let [~alias ~x] ~form))
([x alias form & more]
(let [y `(->>> ~x ~alias ~form)]
`(->>> ~y ~@more
(->>> "test-string-with-lots-of-dashes"
x (s/split x #"-")
Hiya,
There the main arguments are 99% of the times the first or the last ones.
> So -> or ->> will work.
>
Just made a quick search on `main arguments` on both Google and Wikipedia.
Do you mean the arguments in `public static void main (String[] args)`? If
not please provide some definition wh
This email just in case any Googler's stumble across this thread searching for
a generalized threading macro (and a happy conclusion to it). Googling for
examples on this macro was very difficult in my experience, so maybe this might
help someone.
As I found out via the "The case for as->> ("as
2010/7/7 aria42 :
> I've needed --> a few times in my code. I don't think I need it as
> much as just -> or ->>. Most of the time I've needed it is because I
> or someone else essentially had parameters
> in the wrong order. Maybe it belongs in contrib along with -?> which
> I've needed sparingly a
I've needed --> a few times in my code. I don't think I need it as
much as just -> or ->>. Most of the time I've needed it is because I
or someone else essentially had parameters
in the wrong order. Maybe it belongs in contrib along with -?> which
I've needed sparingly as well, but have found usefu
> And I don't think you should be ashamed to admit that.
That's a relief! ;-)
> helpful learning tool, or "training wheels" if you will, is not only
> prudent, but shows that people find the placeholder syntax
> of --> to be intuitive.
I should say that while I do think that the ,,, trick could
I think I've gotten too involved in this not-very-important debate for my own
good. :-D
So just FYI, this will be my last response. If you want a reply from me please
contact me off-list.
If I offended anyone, you have my apologies.
May the force be with you,
- Greg
--
You received this mes
> The use of the commas helped it to click for me a long time ago
And I don't think you should be ashamed to admit that.
The threading macros are not intuitive, and the comma trick *is* useful to help
in learning them.
Rich said:
> I think that is a terrible practice and should be left out of t
> I think that is a terrible practice and should be left out of the book.
Sold! It gives us enough room to put the infix example back in. :O
;-)
:f
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googl
> 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
Well "The Joy of Clojure" is clearly wrong! Actually, the latest
version says "You can
On Jul 6, 2010, at 8:02 PM, Michał Marczyk wrote:
On 7 July 2010 00:36, Greg wrote:
Again, even The Joy of Clojure points out that people use commas
with -> and ->> to indicate the location of the parameter.
I think that is a terrible practice and should be left out of the book.
Rich
On 7 July 2010 00:36, Greg wrote:
> Again, even The Joy of Clojure points out that people use commas with -> and
> ->> to indicate the location of the parameter.
I've yet to see someone actually doing this (and I'm including the
Authors here).
Sincerely,
Michał
--
You received this message be
> Now *that's* a reasonable and rational argument against including -->. :-)
On second thought, I don't think it is.
I know I said I'd let it rest, and I *am* letting it rest in that I've resigned
myself to the understanding that you've made your decision and don't have plans
on changing it. Bu
> 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 otherw
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 wha
On 6 July 2010 22:24, 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
On 6 July 2010 22:02, Greg 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 someth
Hi,
Am 06.07.2010 um 23:24 schrieb Greg:
>> 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 bac
On Tue, Jul 6, 2010 at 3:37 PM, Scott Jaderholm wrote:
>
> On Tue, Jul 6, 2010 at 3: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 on
On Tue, Jul 6, 2010 at 3: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 ba
Thanks for the reply Nicolas!
I might do that if I have more to offer than a single macro, as of now I think
it'd be weird to create a clojar just for that.
It's easily accessible for anyone who searches the list though (or thinks of it
themselves, as others have done). :-)
The code is pretty
> 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 cod
Reading this thread, I realized how happy I was that I use a Lisp where
anyone can create
its own language construct with a new macro.
Greg, put that macro in a repository and in a jar on clojar, easily
accessible from lein,
and maybe people will use it. (I never had the need for something like
On Tue, Jul 6, 2010 at 5:02 PM, Greg 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 t
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 *
> 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.
On Tue, 6 Jul 2010 16:16:37 -0400
Greg 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 ca
On Tue, Jul 6, 2010 at 4:16 PM, Greg 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.
>
On 07/06/2010 04:16 PM, Greg 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.
I don't think
On Jul 6, 2010, at 3:16 PM, Greg 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.
It'
> 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
On Jul 6, 2010, at 4:14 PM, Mike Meyer wrote:
> O
> 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
We try to keep a civil tone here; please do likewise.
On Jul 6, 11:36 am, Greg wrote:
> On Jul 6, 2010, at 2:26 PM, Wilson MacGyver wrote:
>
> > On Tue, Jul 6, 2010 at 2:01 PM, Stuart Halloway
> > wrote:
> >> In my experience, unneeded versatility == support headache.
>
> > I couldn't agree m
On Tue, 6 Jul 2010 14:09:18 -0400
Greg 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
On Tue, Jul 6, 2010 at 2:36 PM, Greg wrote:
> On Jul 6, 2010, at 2:26 PM, Wilson MacGyver wrote:
>
>> On Tue, Jul 6, 2010 at 2:01 PM, Stuart Halloway
>> wrote:
>>> In my experience, unneeded versatility == support headache.
>>
>> I couldn't agree more. I'm happy to see selection of what goes into
On Tue, Jul 6, 2010 at 2:36 PM, Greg wrote:
> On Jul 6, 2010, at 2:26 PM, Wilson MacGyver wrote:
>
> > On Tue, Jul 6, 2010 at 2:01 PM, Stuart Halloway
> > wrote:
> >> In my experience, unneeded versatility == support headache.
> >
> > I couldn't agree more. I'm happy to see selection of what goe
On Jul 6, 2010, at 2:26 PM, Wilson MacGyver wrote:
> On Tue, Jul 6, 2010 at 2:01 PM, Stuart Halloway
> 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
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 chai
> 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
- Greg
On Jul 6, 2010, at 1:58 PM, Greg wrot
On Tue, Jul 6, 2010 at 2:01 PM, Stuart Halloway
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.
--
Omnem crede diem tibi diluxisse supremum.
--
You received th
> And it's implementation is not that trivial:
Excellent point! I've modified --> so that now it's even more versatile and
only evaluates the functions once.
Now this is possible:
user=> (--> 1 (+ 1 _) (do (println "sideeffect!") _) (hash-map :a _ :b
(+ 3 _)) :b)
sideeffect!
(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.
S
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 loc
Hi,
On Jul 6, 5:47 pm, Stuart Halloway wrote:
> There is not general agreement that something like --> is more readable. (I
> for one disagree, at least so far.)
And it's implementation is not that trivial:
user=> (macroexpand '(--> (launch-rockets-if-called-twice)
(call :first _ :second _)))
There is not general agreement that something like --> is more readable. (I for
one disagree, at least so far.)
Stu
> On Jul 6, 2010, at 8:23 AM, Meikel Brandmeyer wrote:
>
>> Hi,
>>
>> this comes up once in a while. See eg. here for an in-depth
>> discussion:
>> http://groups.google.com/grou
On Jul 6, 2010, at 8:23 AM, Meikel Brandmeyer wrote:
> Hi,
>
> this comes up once in a while. See eg. here for an in-depth
> discussion:
> http://groups.google.com/group/clojure/browse_thread/thread/66ff0b89229be894/c3d4a6dae45d4852
So why hasn't it been incorporated yet into the standard libra
Hi,
this comes up once in a while. See eg. here for an in-depth
discussion:
http://groups.google.com/group/clojure/browse_thread/thread/66ff0b89229be894/c3d4a6dae45d4852
Note, that you can ease your pain a little with #(): (-> 3 (#(+ 1 %
4)) (#(prn "answer:" %))). This is rather ugly, though.
S
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
66 matches
Mail list logo
