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 #"-")
y (interleave y (range))
z (s/join #"_" z)
z (s/join " * " ["I am serious" z "Not Kidding!!" z]))
> "I am serious * test_0_string_1_with_2_lots_3_of_4_dashes_5 * Not
Kidding!! * test_0_string_1_with_2_lots_3_of_4_dashes_5"
So... when are we including it in the core?
Cheers,
D.
On Tuesday, July 6, 2010 11:36:14 PM UTC+1, Greg wrote:
>
> > 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 [email protected]<javascript:>
> > Note that posts from new members are moderated - please be patient with
> your first post.
> > To unsubscribe from this group, send email to
> > [email protected] <javascript:>
> > 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 [email protected]
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
[email protected]
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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
