☰

GHC のスタイルへの影響 -Wall 質問する

tag-icon • tag-icon haskell coding-style warnings compiler-warnings ghc
GHC のスタイルへの影響 -Wall 質問する

で GHC 警告を有効にすることは良い習慣と考えられています-Wall。ただし、これらの警告を修正すると、一部の種類のコード構造に悪影響があることがわかりました。

例1:

の do 記法と同等の形式を使用すると、次の形式f >>を明示的に使用しないと警告が生成されます_ <- f。

Warning: A do-notation statement discarded a result of type Char.
         Suppress this warning by saying "_ <- f",
         or by using the flag -fno-warn-unused-do-bind

の結果を使用して何かを行うのを忘れる可能性があることは理解していますf。ただし、結果を無視することは正当です (パーサーでは非常に一般的です)。 を使用する場合、警告は表示されませ>>んよね? を使用すると_ <-、必要以上に重くなります。

例2:

パターン変数に可視関数と同じ名前を付けると、次のようになります。

Warning: This binding for `map' shadows the existing binding
           imported from Prelude

名前空間が大きくなるにつれて、レコード構文を使用すると状況は悪化します。汚染されたすぐに解決できます。解決策は、パターン式で別の名前を付けることです。そのため、警告を回避するためだけに、あまり適切ではない名前を使用することになります。十分な理由ではないと思います。

-fno-warn-...オプションを使用できることはわかっていますが、結局のところ、-Wallそれに固執するべきでしょうか?

ベストアンサー1

例1:

私は Applicative スタイルでパーサーを書くことを再学習しました。これははるかに簡潔です。たとえば、次のコードの代わりに:

funCallExpr :: Parser AST
funCallExpr = do
    func <- atom
    token "("
    arg <- expr
    token ")"
    return $ FunCall func arg

代わりに私はこう書きます:

funCallExpr :: Parser AST
funCallExpr = FunCall <$> atom <* token "(" <*> expr <* token ")"

しかし、何と言っても、警告が気に入らない場合は、警告に従って無効にしてください。

例2:

そうですね、私もその警告には少しイライラします。でも、そのおかげで何度か助かりました。

これは命名規則と結びついています。私はモジュールをかなり小さく保ち、ほとんどのインポートを修飾したままにすることを好みます ( や のような「表記」インポートを除くControl.Applicative) Control.Arrow。これにより、名前の競合の可能性が低くなり、作業が簡単になります。hothasktagsタグを使用している場合、このスタイルは許容されます。

同じ名前のフィールドでパターン マッチングを行う場合は、-XNamedFieldPunsまたは-XRecordWildCardsを使用して名前を再利用できます。

data Foo = Foo { baz :: Int, bar :: String }

-- RecordWildCards
doubleBaz :: Foo -> Int
doubleBaz (Foo {..}) = baz*baz

-- NamedFieldPuns
reverseBar :: Foo -> String
reverseBar (Foo {bar}) = reverse bar

もう一つの一般的な慣例は、レコード ラベルにハンガリー語の接頭辞を追加することです。

data Foo = Foo { fooBaz :: Int, fooBar :: String }

しかし、レコードはHaskellで扱うには面白くありません。とにかく、モジュールを小さくし、抽象化をしっかりしておけば、これは問題にならないはずです。これは次のような警告だと考えてください。シンプルにしろよ。

おすすめ記事