10

私のプログラムでhlintを実行すると、次のエラーが報告されました。

\x -> [x]

代替形式を提案しました

(: [])

hlintによると、最初の形式について何が間違っているのでしょうか。したがって、なぜ（読みにくい）2番目のオプションを使用する必要があるのでしょうか。

編集

（質問に明示的にhlintを追加しました）

私の質問は、語彙の観点からの違いは何であるか（私は両方を理解しています）にはあまりありません。私の問題は、hlintがそれをエラーとしてマークしている理由がわからないことです。たとえば、怠惰に違いはありますか？さらに、なぜ以前はhlintが誤っている\x -> Just xと考えていたのに、警告しか出さなかったのですか。

4

3 に答える 3

15

HLintマニュアルに回答を追加したばかりの一般的な質問。それは言う：

すべてのヒントには重大度レベルがあります。

  • エラー -たとえば、「エラー」の重大度のヒントとしてconcat (map f x)提案されます。concatMap f xスタイルの観点からは、との組み合わせを常にconcat。mapに置き換える必要がありconcatMapます。両方の式が同等であることに注意してください。HLintは、コードの実際のエラーではなく、スタイルのエラーを報告しています。
  • 警告-たとえば、「警告」の重大度のヒントとしてx !! 0提案します。head x通常head、リストの最初の要素を表現する簡単な方法です。特に、リストを帰納的に扱っている場合はそうです。ただし、式f (x !! 4) (x !! 0) (x !! 7)では、真ん中の引数をheadに置き換えると、パターンを追跡するのが難しくなり、おそらく悪い考えです。警告のヒントはしばしば価値がありますが、盲目的に適用されるべきではありません。

エラーと警告の違いは、個人的な好みの1つであり、通常は私の個人的な好みです。Haskellスタイルの感覚がすでに十分に発達している場合は、その違いを無視する必要があります。Haskellの初心者プログラマーであれば、警告のヒントの前にエラーのヒントに焦点を当てることができます。

個人的な趣味の違いはありますが、気が変わることもあります。このスレッドの2つの例を見ると、比較的「複雑な」ヒントのように見えます。パターンマッチングを行わない場合は、リストの抽象化を一般的なコンテナとして抽象化することで、糖衣(:[])構文を分解しています。それ。とは対照的に、常に良い考えのようです。したがって、HLint-1.8.43（リリースされたばかり）では、最初に警告を出し、2番目にエラーを出しました。[x]x:[]\x -> Just xJust

于 2013-01-27T22:43:10.297 に答える
12

本当の違いはありません。HLintはスタイルの問題に関心があります。最終的には、コードの見栄えを良くするためのヒントにすぎません。

一般に、そのようなコンストラクターまたは関数でラムダを使用すると冗長になり、コードが読みにくくなります。Just極端な例として、例のようなコンストラクターを取り上げJustます\ x -> Just x。これらは同等ですが、2番目のバージョンは確かに物事をより混乱させます！より近い例として、ほとんどの人はを選択(+ 1)し\ x -> x + 1ます。

あなたの特定のケースでは、リストには特別な構文があるので、それは別の話です。\ x -> [x]したがって、バージョンの方が気に入った場合は、そのままにしておいてください。ただし、演​​算子セクションに慣れると、その(: [])バージョンは読みやすい（簡単ではないにしても）と思われる可能性が高いため、今でも使用することを検討してください。

于 2013-01-25T21:27:40.103 に答える
7

return私はこれを使用することを検討するかもしれませんpure：

ghci> return 0 :: [Int]
[0]

ghci> import Control.Applicative
ghci> pure 0 :: [Int]
[0]

:: [Int]私はGHCiで働いていたので、型注釈（）を含める必要がありました。他のたくさんのコードの真ん中で、あなたはおそらくそれを必要としないでしょう。

于 2013-01-26T09:16:12.187 に答える