代入と参照透過性を取り巻く技術的課題

ウィキペディア小見出し辞書

代入と参照透過性を取り巻く技術的課題

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2018/10/03 03:23 UTC 版)

「参照透過性」の記事における「代入と参照透過性を取り巻く技術的課題」の解説

参照透過性が成り立つような言語では変数の値を定義する構文はあっても変数の値を再定義するような変数への代入 (Assignment) を行う構文は存在せず、ある式の値、例えば関数値、変数値についてどこに記憶されている値を参照しているかということを考慮する必要がない。 ただこのような違いがありながらも参照透過性の有無は、計算理論上は言語の記述能力を左右しない。代入はプログラム、またその要素である関数内での変数の変更を許す、つまり内部状態を作るため数学的にはチューリングマシンのような状態機械でモデル化できる一方、純粋関数型言語はラムダ計算でモデル化できるが、両者で記述できるプログラムの集合は同一であることが証明されているからである。とはいえ、人間にとっての記述しやすさ、可読性、現時点の技術で実現した場合の実行効率などは両者で当然異なる。 例えば関数値、変数値についてどこに記憶されている値を参照しているかということを考慮する必要がないということは記憶領域の使い方の管理がプログラマの手から完全に離れているということを意味するため、プログラムの表現を簡明にすることに寄与する一方で、実行効率向上のためには言語処理系によるデータの管理と最適化を多分に必要とする。具体的な例を挙げれば、参照透過性が成り立つような言語では大きなデータ構造（例えば要素数の多い配列やレコード型など）の極一部を変更するような場合でも主記憶上にあるデータ構造の一部だけを単純に書き直すことが出来ない（例えばAとBが同じ式で配列として定義されているときにBの3番目を変更したらAの3番目をアクセスする式の値がどうなるか）。 また、当然のことながら参照透過性が成り立つような言語では参照され共有されている記憶領域に格納された値を監視するようなコードは書けない。このことはプログラムの動作を副作用の考察なしに追跡し、その実行をスケジューリングできるというようにプログラム理解を簡単にし最適化の可能性を広げる一方で、変数で同期を取るような素朴な並行・並列処理プログラムは最早書けず、入力動作を表現するためには様々な工夫が必要となり、スケジューリングに左右されないように出力を順序正しく行うためにも様々な工夫が必要となることを意味する。 以上のような理由からMLのように、基本的には関数型を指向して作られていながら補助的に代入の機能も備え、式に状態を持たせられるようにするケースがしばしばある。Haskellではモナド (Monad) 型と構文糖衣を利用して参照透過性を保ったまま手続き型的な表現を可能にしている。また、Haskellと相互に影響を与え合ったもう一つの純粋関数型言語Cleanでは、一度参照したら二度と参照しないという一意性をその値の型に付加属性として与え、代入を利用しつつ参照透過性を維持し、効率化も実現している。