> 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. But I made a mistake in sounding like I agreed with your
arguments, so let me know just correct that (you don't have to reply or even
read this).
>> At a glance, people will presume that prints the same thing twice
At a glance, people will not have any correct idea of what most Lisp code does
without reading the documentation, and this applies doubly-so for macros. Look
at either the -> or ->> forms, or templates, etc, and you could make the exact
same statement about how incorrect someone's first impression would be about
them.
For example, here's something from core.clj that uses ->
(-> bvec (conj gvec) (conj val))
"At a glance", people will presume a function called -> is being called, with
the arguments bvec, (conj gvec), and (conj val).
So, in other words, if you're actually serious about this argument, then you
should do away with -> and ->> because the same applies to them. They're not
intuitive "at a glance."
>> _ is an input, then a result. Why give it the same name?
No, _ is an input in all cases. It's the input from the form preceding it. You
also have the same situation with -> and ->>.
So, it's a shame --> won't be included in the core, but I don't think it's a
tragedy. :-p
- Greg
On Jul 6, 2010, at 6:36 PM, 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 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
