>>59
うん？
>>55に挙げられてる４つの文献のguardの解説なら見たよ
その感想は、そこで“guard”と呼ばれてるのは通常のif〜else if〜else if〜elseの書き方を少し変えただけ（つまり、只のお化粧）で
if expressionの各分岐の条件式の位置（インデンテーション）を揃えて見やすくしているだけの代物に過ぎないということだよ

そもそも、そんな見掛けのお化粧だけのものを“guard”などと大袈裟な名前で呼ぶのが根本的に間違っている

私の知る限りでは、“guard”という言葉を使い始めたのはEdsger W. Dijkstraが
命令的プログラムを論理的な導出する考え方の説明のために
専用のミニ言語 ― いわゆる彼のガード付き命令(Guarded Commands) ― を提案する際に
従来の決定性の（つまり多分岐での多数の条件部の成立・不成立の判定が
固定された順番…ソース上での条件部の現れている順番…で行われる）通常のif〜else if〜else if〜else文を批判して
一連の文の並びを実行して良い条件をguardと呼んで、このguardを付加した文（または文の並び）をguarded commandと呼び
場合分け（条件分岐）ではキーワードif/fiの間に、ループの場合にはキーワードdo/odの間に、１個以上のguarded commandを
並記するようにしたのだ

Dijkstraのguarded commandの特徴は、例えば条件分岐の場合、複数のguarded commandsのguard同士には重なりがあっても良く、
重なりがある場合にはソースコード上での出現順序とは無関係にどちらのguardが開く（それが付加している（あるいは一部の日本語訳だと
蓋している）命令文が実行されても良い…即ち非決定性を積極的に許す…ということだ

そして確かに論理に基づくプログラム導出では彼のガード付き命令で持ち込まれた非決定性はとても便利で重要な概念的ツールとして働く

ところが、この関数プログラミングコミュニティが“guard”と呼んでいるのは単なるif式の書き方を少し変えただけの代物に過ぎない
そんなものを“guard”なんて大袈裟な名前で呼ぶのは羊頭狗肉の類だ

（それに比べると、まだパターンマッチングに関しては、局所変数の導入とそれと値との束縛(binding)を自動的に行うという意味で
単純にはifに書き換えできないという点で自明でない工夫や進歩が成されたとポジティブに評価できる）