blocks|key|3252582|text|这只是一个风格问题。然而，这本书的方式对我来说更有意义。它组成所有函数，然后将其应用于值。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3252583|你的方法看起来很奇怪，最后一个$是不必要的。|offset|length|style|CODE|3252584|然而，这真的无关紧要。在Haskell中，通常有很多很多正确的方法来做同样的事情。|3252585|entityMap^0|0|F|1|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@$D|N|E|O|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

It's just a matter of style. However, the way the book does it makes more sense to me. It composes all the functions, and then applies it to the value.

Your method just looks strange, and the last <code>$</code> is unnecessary.

However, it really doesn't matter. In Haskell, there are usually many, many, correct ways to do the same thing.

blocks|key|302678|text|我想我可以从权威人士那里回答这个问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|302679|302680|使用图书的方式比使用所有($)符号要好得多，这是有原因的吗？|blockquote|302681|302682|302683|没有什么特别的原因。布莱恩和我都更喜欢减少线路噪音。.比$更安静。因此，本书使用了f+.+g+.+h+$+x语法。|offset|length|style|CODE|302684|entityMap^0|0|0|0|0|0|Q|1|S|1|15|D|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|R|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]|$1|G|3|-4|5|6|7|T|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|U|8|@$J|V|K|W|L|M]|$J|X|K|Y|L|M]|$J|Z|K|10|L|M]]|9|@]|A|$]]|$1|N|3|-4|5|6|7|11|8|@]|9|@]|A|$]]]|O|$]]

I guess I can answer this from authority.

<blockquote>
 Is there a reason for using the books way that is much better than using all ($) symbols?
</blockquote>

There's no special reason. Bryan and I both prefer to reduce line noise. <code>.</code> is quieter than <code>$</code>. As a result, the book uses the <code>f . g . h $ x</code> syntax.

blocks|key|3038424|text|它们实际上是等价的:请记住，$操作符本质上什么也不做。f+$+x的计算结果为f+x。$的目的是它的固定行为:右关联和最小优先级。删除$并使用括号进行分组，而不是使用中缀优先级，代码片段如下所示：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3038425|k+=+a+(b+(c+(value)))|code-block|syntax|javascript|3038426|和|3038427|k+=+(a+.+b+.+c)+value|3038428|与$版本相比，更喜欢.版本的原因与更喜欢两者而不是上面带括号的版本的原因是相同的:美学吸引力。|3038429|尽管，有些人可能会想，使用中缀运算符而不是括号是否基于某种潜意识的冲动，以避免与Lisp可能的任何相似之处(只是开玩笑...我想？)。|3038430|entityMap^0|E|1|R|5|12|3|16|1|1U|1|0|0|0|0|1|1|A|1|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@$9|V|A|W|B|C]|$9|X|A|Y|B|C]|$9|Z|A|10|B|C]|$9|11|A|12|B|C]|$9|13|A|14|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|15|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|16|8|@]|D|@]|E|$]]|$1|M|3|N|5|H|7|17|8|@]|D|@]|E|$I|J]]|$1|O|3|P|5|6|7|18|8|@$9|19|A|1A|B|C]|$9|1B|A|1C|B|C]]|D|@]|E|$]]|$1|Q|3|R|5|6|7|1D|8|@]|D|@]|E|$]]|$1|S|3|-4|5|6|7|1E|8|@]|D|@]|E|$]]]|T|$]]

They are indeed equivalent: Keep in mind that the <code>$</code> operator does, essentially, nothing. <code>f $ x</code> evaluates to <code>f x</code>. The purpose of <code>$</code> is its fixity behavior: right-associative and minimal precedence. Removing <code>$</code> and using parentheses for grouping instead of infix precedence, the code snippets look like this:

<pre><code>k = a (b (c (value)))
</code></pre>

and

<pre><code>k = (a . b . c) value
</code></pre>

The reason for preferring the <code>.</code> version over the <code>$</code> version is the same reason for preferring both over the very parenthesized version above: aesthetic appeal.

Although, some might wonder if using infix operators instead of parentheses is based on some subconscious urge to avoid any possible resemblance to Lisp (just kidding... I think?).

blocks|key|305017|text|对我来说，我认为答案是(a)整洁，就像Don+said；以及(b)我发现当我编辑代码时，我的函数可能以无指针的方式结束，然后我所要做的就是删除最后一个$，而不是返回并更改所有东西。当然，这是一个次要的问题，但也是一个很好的问题。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|305018|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/3030675/haskell-function-composition-and-function-application-idioms-correct-use/3030779#3030779^0|23|1|J|8|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@$9|O|A|P|B|C]]|D|@$9|Q|A|R|1|S]]|E|$]]|$1|F|3|-4|5|6|7|T|8|@]|D|@]|E|$]]]|G|$H|$5|I|J|K|E|$L|M]]]]

For me, I think the answer is (a) the neatness, as <a href="https://stackoverflow.com/questions/3030675/haskell-function-composition-and-function-application-idioms-correct-use/3030779#3030779">Don said</a>; and (b) I find that when I'm editing code, my function may end up in point-free style, and then all I have to do is delete the last <code>$</code> instead of going back and changing everything. A minor point, certainly, but a nicety.

blocks|key|3038545|text|在this+haskell-cafe+thread上有一个关于这个问题的有趣讨论。显然，有少数观点认为$的正确关联性是"just+plain+wrong"，而选择f+.+g+.+h+$+x而不是f+$+g+$+h+$+x是回避问题的一种方式。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3038546|entityMap|0|LINK|mutability|MUTABLE|url|http://www.mail-archive.com/haskell-cafe@haskell.org/msg12528.html|1|http://www.mail-archive.com/haskell-cafe@haskell.org/msg12549.html^0|1F|1|29|D|2P|D|1|O|0|1N|I|1|0^^$0|@$1|2|3|4|5|6|7|P|8|@$9|Q|A|R|B|C]|$9|S|A|T|B|C]|$9|U|A|V|B|C]]|D|@$9|W|A|X|1|Y]|$9|Z|A|10|1|11]]|E|$]]|$1|F|3|-4|5|6|7|12|8|@]|D|@]|E|$]]]|G|$H|$5|I|J|K|E|$L|M]]|N|$5|I|J|K|E|$L|O]]]]

There's an interesting discussion of this question on <a href="http://www.mail-archive.com/haskell-cafe@haskell.org/msg12528.html" rel="noreferrer">this haskell-cafe thread</a>. Apparently there's a minority viewpoint that holds that the right associativity of <code>$</code> is <a href="http://www.mail-archive.com/haskell-cafe@haskell.org/msg12549.html" rel="noreferrer">"just plain wrong"</a>, and choosing <code>f . g . h $ x</code> over <code>f $ g $ h $ x</code> is one way of side-stepping the issue.

blocks|key|302750|text|我要补充的是，在f+.+g+$+x中，f+.+g是一个有意义的语法单元。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|302751|同时，在f+$+g+$+x中，f+$+g不是一个有意义的单元。可以说，$链更有必要--首先获得x的g的结果，然后对其执行f，然后对其执行foo，然后依此类推。|302752|同时，.链可以说更具声明性，在某种意义上更接近以数据流为中心的视图--组成一系列函数，并最终将它们应用于某些东西。|302753|entityMap^0|8|9|J|5|0|4|9|F|5|Z|1|1B|1|1D|1|1O|1|1W|3|0|3|1|0^^$0|@$1|2|3|4|5|6|7|L|8|@$9|M|A|N|B|C]|$9|O|A|P|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Q|8|@$9|R|A|S|B|C]|$9|T|A|U|B|C]|$9|V|A|W|B|C]|$9|X|A|Y|B|C]|$9|Z|A|10|B|C]|$9|11|A|12|B|C]|$9|13|A|14|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|15|8|@$9|16|A|17|B|C]]|D|@]|E|$]]|$1|J|3|-4|5|6|7|18|8|@]|D|@]|E|$]]]|K|$]]

I'd add that in <code>f . g $ x</code>, <code>f . g</code> is a meaningful syntactic unit. 

Meanwhile, in <code>f $ g $ x</code>, <code>f $ g</code> is not a meaningful unit. A chain of <code>$</code> is arguably more imperative -- first get the result of <code>g</code> of <code>x</code>, then do <code>f</code> to it, then do <code>foo</code> to it, then etc. 

Meanwhile a chain of <code>.</code> is arguably more declarative, and in some sense closer to a dataflow centric view -- compose a series of functions, and ultimately apply them to something.

blocks|key|3252796|text|我意识到这是一个非常古老的问题，但我认为还有另一个原因没有被提及。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3252797|如果要声明一个新的无点函数f+.+g+.+h，则会自动应用您传入的值。但是，如果您编写f+$+g+$+h，它将无法工作。|offset|length|style|CODE|3252798|我认为作者更喜欢组合方法的原因是它导致了构建函数的良好实践。|3252799|entityMap^0|0|D|9|17|9|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@$D|N|E|O|F|G]|$D|P|E|Q|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|K|$]]

I realize this is a very old question, but I think there is another reason for this that hasn't been mentioned.

If you are declaring a new point-free function <code>f . g . h</code>, the value you pass in will be automatically be applied. However, if you write <code>f $ g $ h</code>, it will not work.

I think the reason the author prefers the composition method is because it leads to a good practice of building up functions.

I have been reading Real World Haskell, and I am nearing the end, but a matter of style has been niggling at me to do with the <code>(.)</code> and <code>($)</code> operators.

When you write a function that is a composition of other functions you write it like:

<pre><code>f = g . h
</code></pre>

But when you apply something to the end of those functions I write it like this:

<pre><code>k = a $ b $ c $ value
</code></pre>

But the book would write it like this:

<pre><code>k = a . b . c $ value
</code></pre>

Now, to me they look functionally equivalent, they do the exact same thing in my eyes. However, the more I look, the more I see people writing their functions in the manner that the book does: compose with <code>(.)</code> first and then only at the end use <code>($)</code> to append a value to evaluate the lot (nobody does it with many dollar compositions). 

Is there a reason for using the books way that is much better than using all <code>($)</code> symbols? Or is there some best practice here that I am not getting? Or is it superfluous and I shouldn't be worrying about it at all?

Haskell function composition (.) and function application ($) idioms: correct use

数据流

我一直在阅读Real World Haskell，我已经快要读完了，但是关于(.)和($)操作符的风格问题一直困扰着我。当你编写一个由其他函数组合而成的函数时，你可以这样写：f = g . h但是当你在这些函数的末尾应用一些东西时，我会写成这样：k = a $ b $ c $ value但这本书是这样写的：k = a ...

问Haskell函数组合(.)和函数应用($)习惯用法:正确使用
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Haskell函数组合(.)和函数应用($)习惯用法:正确使用EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Haskell函数组合(.)和函数应用($)习惯用法:正确使用
EN