Complete the case of nested pattern match, plus many modifications

Author: igrep

examples/2020/strict-gotchas/tuple.hs

@@ -1,6 +1,6 @@
 -- The result of this example doesn't change whether with or without Strict.
 
-data MyTuple a b = MyTuple a b deriving Show
+data MyTuple a b = MyTuple !a !b deriving Show
 
 main :: IO ()
 main = do

preprocessed-site/posts/2020/strict-gotchas.md

@@ -15,26 +15,27 @@ Haskellは他の多くのプログラミング言語と異なった特徴を持
 遅延評価は、適切に扱えば不要な計算を行わず、計算資源を節約してくれるステキな仕組みですが、一歩使い方を間違うと「サンク」という「これから実行する<small>（かも知れない）</small>計算」を表すオブジェクトが大量の作られてしまい、却ってメモリー消費量が増えてしまう、などといった問題を抱えています。  
 この現象は「スペースリーク」と呼ばれ、かつて[専門のAdvent Calendar](https://qiita.com/advent-calendar/2015/haskell-space-leaks)が作られたことがあるほど、Haskeller達の関心を集めてきました。
 
-そんなHaskeller達の悩みの種を軽減しようと、GHC 8.0以降、[`Strict`](https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#strict-by-default-pattern-bindings)と[`StrictData`](https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#strict-by-default-pattern-bindings)という拡張が搭載されました。  
+そんなHaskeller達の悩みの種を軽減しようと、GHC 8.0以降、[`Strict`](https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#strict-by-default-pattern-bindings)と[`StrictData`](https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#strict-by-default-pattern-bindings)という言語拡張が搭載されました。  
 これらの拡張を大雑把に言うと、
 
 - `StrictData`: 値コンストラクターにおいて、引数の値が弱頭正規形（Weak Head Normal Form。以降慣習に従い「WHNF」と呼びます）まで評価されるようになる
 - `Strict`: `StrictData`の効果に加え、あらゆる関数やローカル変数の定義において、パターンマッチで代入した変数の値がWHNFまで評価されるようになる
 
 というものです。
 
-このうち、`StrictData`は比較的リスクが少なく大変有用（もはや標準であって欲しいぐらい）という声をよく聞きますが[^strictdata-sample]、`Strict`については様々な問題点があることが知られています。  
+このうち、`StrictData`は比較的リスクが少なく大変有用<small>（もはや標準であって欲しいぐらい）</small>という声をよく聞きますが[^strictdata-sample]、`Strict`については様々な問題点があることが知られています。  
 今回はその各種問題点をまとめて共有することで、思い切って`Strict`を有効にするときに参考になる情報を提供したいと思います！
 
-[^strictdata-sample]: 例えばfumievalさんによる[この記事](http://fumieval.hatenablog.com/entry/2015/12/10/200630)。
+[^strictdata-sample]: 例えばfumievalさんによる[この記事](http://fumieval.hatenablog.com/entry/2015/12/10/200630)より:  
+> もっとも、日常ではここまで気にしなければいけない場面は少ないので、ほとんどの場合は気にせず感嘆符をつけて大丈夫だろう。GHC 8.0からは、全フィールドをデフォルトで正格にする`StrictData`という拡張が入るため、こちらを使おう。
 
 # 前提知識とその参考資料
 
 以下の知識について、概要を理解しているものとして進めます。  
 参考になりそうな日本語のページも付記したので、ご覧ください。
 
 - Haskellの遅延評価について
-    - [実装して理解する遅延評価の仕組み 〜 thunkを絵に描いて理解しよう・JavaScriptでHaskellを実装！？ - プログラムモグモグ](https://itchyny.hatenablog.com/entry/20130209/1360417348)が分かりやすいでしょう
+    - [実装して理解する遅延評価の仕組み 〜 thunkを絵に描いて理解しよう・JavaScriptでHaskellを実装！？ - プログラムモグモグ](https://itchyny.hatenablog.com/entry/20130209/1360417348)が詳しくて分かりやすいでしょう
 - Haskellの正格評価について
     - [正格性のすべて (翻訳)](https://haskell.e-bigmoon.com/posts/2018/06-25-all-about-strictness)
 - `Strict`と`StrictData`について
@@ -58,6 +59,8 @@ stack exec runghc -- <これから紹介するコードのファイル>.hs
 
 # Case 1: `where`句だろうとなんだろうと評価
 
+サンプル: [where.hs](https://github.com/haskell-jp/blog/blob/master/examples/2020/strict-gotchas/where.hs)
+
 最初のケースは、遅延評価で当たり前に享受していたメリットが、`Strict`を有効にしている状態では得られなくなってしまう、というものです。  
 [pfxfncさんのStrict拡張でハマったお話](https://qiita.com/pxfnc/items/a26bda6d11402daba675)という記事でも紹介されてはいますが、まとめ記事なのでここでも改めて取り上げます。
 
@@ -108,10 +111,12 @@ where.hs: divide by zero
 
 こうなると、`result`を使用しないケース、すなわち`n == 0    = 0`の場合であっても`result`に <small>（WHNFまで評価した）</small>値を代入するのに必要な計算は実行され、結果<code>10 `div` 0</code>が計算されようとして`divide by zero`が発生するのです。
 
-`where`句は関数定義の後ろの方に書くという性格上、見落としがちかも知れません。注意しましょう。
+⚠️`where`句は関数定義の後ろの方に書くという性格上、見落としがちかも知れません。注意しましょう。
 
 # Case 2: ポイントフリースタイルかどうかで変わる！
 
+サンプル: [const.hs](https://github.com/haskell-jp/blog/blob/master/examples/2020/strict-gotchas/const.hs)
+
 続いて、Haskellに慣れた方なら誰もが一度は試したくなる、ポイントフリースタイルに関する落とし穴です。  
 まずは次の二つの関数をご覧ください。
 
@@ -125,7 +130,7 @@ referArgs x _ = x
 
 この関数、どちらもやっていることは`const`と変わりません。  
 `dontReferArgs`は`const`をそのまま使うことでポイントフリースタイルにしていますが、`referArgs`は自前で引数に言及することで`const`と同等の定義となっています。  
-ポイントフリースタイルに変えると言うことは原則として元の関数の挙動を変えないワケですから、`dontReferArgs`と`referArgs`の意味は変わらないはず、ですよね[^opt]？  
+ポイントフリースタイルに変えると言うことは原則として元の関数の挙動を変えないワケですから、`dontReferArgs`と`referArgs`の意味は変わらないはず、ですよね[^opt]？
 
 [^opt]: 実際のところ今回紹介するケース以外にも、ポイントフリースタイルにするかしないかで実行効率などが変わる場合があります。例えば、[Evaluation of function calls in Haskell](https://treszkai.github.io/2019/07/13/haskell-eval)をご覧ください。
 
@@ -163,11 +168,11 @@ CallStack (from HasCallStack):
 `Strict`拡張を有効にした結果、意図せず例外を発生させる値<small>（今回の場合`undefined`）</small>が評価されてしまったのです。
 
 例外を発生させた関数はそう、ポイントフリースタイルでない、`referArgs`関数の方です！  
-なぜ`referArgs`でのみ例外が発生してしまったのかというと、`referArgs`が`Strict`拡張を有効にしたモジュールで、引数に言及しているからです。  
-`Strict`拡張を有効にした結果「あらゆる関数やローカル変数の定義において、パターンマッチで代入した変数の値」が評価されるようになるとおり、`referArgs`の引数`x`・`_`も必ず評価されるようになり、このような例外が発生したのです。  
+なぜ`referArgs`でのみ例外が発生してしまったのかというと、`referArgs`が`Strict`拡張を有効にしたモジュールで、引数に言及<small>（パターンマッチ）</small>しているからです。  
+`Strict`拡張を有効にした結果「あらゆる関数やローカル変数の定義において、パターンマッチで代入した変数の値」が評価されるとおり、`referArgs`の引数`x`・`_`も必ず評価されるようになり、このような例外が発生したのです。  
 たとえ使用しない変数`_`でも関係ありません！
 
-そのため、原因の本質は引数に言及<small>（してパターンマッチ）</small>しているか否かであり、`Prelude`の`const`を使用しているか否かではありません。  
+そのため、原因の本質は引数に言及<small>（パターンマッチ）</small>しているか否かであり、`Prelude`の`const`を使用しているか否かではありません。  
 こちら👇のように引数に言及した上で`const`を使っても、結果は同じなのです。
 
 ```haskell
@@ -180,11 +185,11 @@ print $ referArgsByConst "referArgsByConst" (undefined :: Int)
 ```
 
 一方、`dontReferArgs`については、引数に言及せず、`Prelude`にある`const`をそのまま使っています。  
-`Strict`拡張ではあくまでも「パターンマッチした変数」のみをWHNFまで評価するようになるものであり、あらゆる関数が正格に呼び出されるわけではありません。  
+`Strict`拡張はあくまでも「パターンマッチした変数」のみをWHNFまで評価するものであり、あらゆる関数が正格に呼び出されるわけではありません。  
 なので通常の`Prelude`における`const`と同様、`dontReferArgs`も第2引数は評価しないため、`undefined`を渡しても例外は起こらなかったのです。
 
-このことは、「`Strict`拡張を有効にしているモジュールの中でも、`Strict`を有効にしていないモジュールから`import`した関数は、引数を正格に評価しない」という忘れてはならないポイントも示しています。  
-例えば`const`よりももっと頻繁に使われるであろう、言及する引数を一つ削除する演算子の代表である、関数合成`.`を使ったケースを考えてみてください。
+このことは、「`Strict`拡張を有効にしているモジュールの中でも、`Strict`を有効にしていないモジュール<small>（この場合は`Prelude`）</small>から`import`した関数は、引数を正格に評価しない」という忘れてはならないポイントも示しています。  
+例えば`const`よりももっと頻繁に使われるであろう、言及する引数を一つ削除する演算子の代表、関数合成`.`を使ったケースを考えてみてください。
 
 ポイントフリースタイルに慣れた方なら、関数適用`$`を次👇のように使って定義した`f`を見ると、
 
@@ -203,10 +208,11 @@ f = map (+ 3) . filter (> 2)
 
 しかし、`Strict`を有効にしたモジュールでこのような書き換えを行うと、`f`の挙動が変わってしまいます。  
 引数`.`を使って書き換える前は、引数`xs`に言及していたところ`.`を使って引数`xs`に言及しなくなったからです。  
-こうした書き換えによって、**`Strict`拡張を有効にしていても意図せず遅延評価してしまう**というリスクがあるので、リファクタリングの際はくれぐれも気をつけてください[^list]。  
+`filter`も`map`も`Strict`拡張を有効にしたモジュールで定義されているわけではないので、引数を正格に評価しないんですね。  
+結果、こうした書き換えによって、**`Strict`拡張を有効にしていても意図せず遅延評価してしまう**、というリスクがあるので、リファクタリングの際はくれぐれも気をつけてください[^list]。  
 ざっくりまとめると、`Strict`拡張を有効にしているモジュールでは、「引数や変数を宣言することすなわちWHNFまで評価すること」、あるいは「引数や変数を宣言しなければ、評価されない」と意識しましょう。
 
-[^list]: もっとも、この場合引数はリストでしょうから、WHNFまでのみ正格評価するメリットは少なそうですが。
+[^list]: もっとも、この場合引数は多分リストでしょうから、WHNFまでのみ正格評価するメリットは少なそうですが。
 
 ちなみに、`referArgs`における`_`のように「`Strict`拡張を有効にした場合さえ、使用していない引数が評価されてしまうのは困る！」という場合は、引数名の前にチルダ`~`を付けてください。
 
@@ -215,15 +221,69 @@ referArgs :: a -> b -> a
 referArgs x ~_ = x
 ```
 
-# Case hoge: 内側のパターンはやっぱりダメ
+# Case 3: 内側のパターンはやっぱりダメ
 
-hoge
+サンプル: [tuple.hs](https://github.com/haskell-jp/blog/blob/master/examples/2020/strict-gotchas/tuple.hs)
+
+続いては、`Strict`拡張のドキュメントでも触れられている、入れ子になったパターンマッチングにおける問題を紹介します。  
+一言で言うと、`let (a, b) = ...`のような、データ構造<small>（この場合タプルですね）</small>の「内側」に対するパターンマッチは、`Strict`拡張を有効にしていても正格に評価しないよ、という話です。
+
+例えば、下記のコードを`Strict`拡張付きで実行しても、パターンマッチしている`a`・`b`ともに代入した時点では正格評価されず、`error "a"`・`error "b"`による例外はいずれも発生しません。
+
+```haskell
+(a, b) = (error "a", error "b")
+```
+
+これは、タプルの値コンストラクター`(,)`が<small>（`StrictData`やStrictness flagを用いないで定義されているので）</small>各要素を遅延評価することとは**関係なく**、各要素を正格評価する値コンストラクターであっても同様です。
+
+```haskell
+data MyTuple a b = MyTuple !a !b deriving Show
+
+MyTuple a b = MyTuple (error "a") (error "b")
+```
+
+先ほどの節における「`Strict`拡張を有効にしているモジュールでは、『引数や変数を宣言することすなわちWHNFまで評価すること」』、あるいは『引数や変数を宣言しなければ、評価されない』と意識しましょう」という主張を真に受けてしまうと意図せず遅延評価させてしまい、ハマりそうです😰。  
+⚠️繰り返しますが「内側のパターンにおける変数は正格評価されない」ということも意識してください。
 
-# Case hoge: `foldl`と`foldr`
+以上のことを試していただくために、サンプルコードでは`Strict`を有効にしてもしなくても、結果が変わらないサンプルを用意しました<small>（コードは👆の例に`main`がくっついたのとあまり変わらないので省きます）</small>。  
+以下、実行例を。
+
+```bash
+> stack exec runhaskell ./tuple.hs
+"Default tuple"
+"Default tuple in MyTuple1"
+"Other value in MyTuple1"
+
+> stack exec -- runghc --ghc-arg=-XStrict .\tuple.hs
+"Default tuple"
+"Default tuple in MyTuple1"
+"Other value in MyTuple1"
+```
+
+# Case 4: `foldl`と`foldr`
+
+ここの話はちょっと難しいので、先に守るべくルールを述べておきます。  
+「遅延評価する関数を受け取る前提の高階関数に、
+
+より具体的には、`foldr`に<small>（`Strict`拡張などで）</small>引数を正格に評価するよう定義された関数を渡すのは止めましょう、という話です。  
+`Strict`拡張を有効にした状態ではラムダ式にも注意しないといけないもポイントです。
+
+サンプル1: [stackoverflow-foldl.hs](https://github.com/haskell-jp/blog/blob/master/examples/2020/strict-gotchas/stackoverflow-foldl.hs)
+
+サンプル2: [stackoverflow-foldr.hs](https://github.com/haskell-jp/blog/blob/master/examples/2020/strict-gotchas/stackoverflow-foldr.hs)
 
 hoge
 
-# Case hoge: `undefined`を受け取るメソッド
+# Case 5: `undefined`を受け取るメソッド
+
+最後は、ちょっとレアケースではありますが、
+
+[#16810: Use explicit lazy binding around undefined in inlinable functions · Issues · Glasgow Haskell Compiler / GHC · GitLab](https://gitlab.haskell.org/ghc/ghc/issues/16810)
+
+サンプル: [storable.hs](https://github.com/haskell-jp/blog/blob/master/examples/2020/strict-gotchas/storable.hs)
 
 hoge
 
+# おわりに: やっぱり`Strict`は使う？使わない？
+
+hoge