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
