したがって、関数型言語でのパターン マッチングは非常に優れています。ほとんどの命令型言語がこの機能を実装していないのはなぜですか? 私の理解では、Scala はパターン マッチングを備えた唯一の「主流」の命令型言語です。ケース/スイッチ構造は、それほど強力ではありません。
特に、パターン マッチングの欠如が技術的な理由によるものなのか、それとも歴史的な理由によるものなのかに興味があります。
したがって、関数型言語でのパターン マッチングは非常に優れています。ほとんどの命令型言語がこの機能を実装していないのはなぜですか? 私の理解では、Scala はパターン マッチングを備えた唯一の「主流」の命令型言語です。ケース/スイッチ構造は、それほど強力ではありません。
特に、パターン マッチングの欠如が技術的な理由によるものなのか、それとも歴史的な理由によるものなのかに興味があります。
主に歴史的なものです。パターン マッチング (さらに言えば代数データ型) は、関数型言語 Hope のために 1980 年頃に発明されました。そこからすぐに ML になり、後に Miranda や Haskell などの他の関数型言語に採用されました。主流の命令型の世界では、通常、新しいプログラミング言語のアイデアを採用するのにさらに数十年かかります。
採用が特に妨げられた理由の 1 つは、メインストリームが長い間オブジェクト指向のイデオロギーに支配されてきたことです。その世界では、オブジェクトやサブタイプによって表現されないものはすべて、道徳的に「間違っている」と見なされます. 代数データ型は、それに対する一種のアンチテーゼであると主張する人もいるかもしれません。
おそらく、関数型言語でより自然にするいくつかの技術的な理由もあります。
通常のスコープ規則と変数のきめの細かいバインディング構造は、関数型言語では標準ですが、主流の命令型言語ではあまり一般的ではありません。
パターンは不変変数をバインドするため、特にそうです。
型チェック パターンの一致は、関数型システムのより整形式の構造と剛性、および計算ロジックとの密接な関係に依存しています。主流タイプのシステムは、通常、それとはかけ離れています。
代数データ型にはヒープ割り当てが必要であり (多くのスペースを浪費して再帰を禁止したい場合を除きます)、ガベージ コレクションがないと非常に不便です。ただし、主流の言語の GC が存在する場合、GC は通常、軽量の関数データではなく、重量のオブジェクト用に最適化されています。
技術的な理由よりも歴史的な理由だと思います。パターン マッチングは、歴史的に関数型言語にも関連付けられている代数データ型でうまく機能します。
Scala はおそらく、パターン マッチングを使用する命令型言語の悪い例です。なぜなら、それを強制するわけではありませんが、関数型スタイルを好む傾向があるからです。
パターンマッチングを備えた現代的でほとんどが命令型の言語の例はRustです。命令型であり、金属上で実行されますが、代数データ型、パターン マッチング、および関数型言語により一般的なその他の機能がまだあります。しかし、そのコンパイラの実装は、C コンパイラの実装よりもはるかに複雑です。