可変状態を維持する関数型言語には何も問題はありません。Haskellなどの「純粋な」関数型言語でさえ、実世界と対話するために状態を維持する必要があります。Clojureのような「不純な」関数型言語では、状態の変化を含む副作用が発生します。
主なポイントは、関数型言語は本当に必要な場合を除き、可変状態を妨げるということです。一般的なスタイルは、純粋な関数と不変のデータを使用してプログラミングし、それを必要とするコードの特定の部分の「不純な」可変状態とのみ対話します。そうすれば、コードベースの残りを「純粋」に保つことができます。
STMが関数型言語でより一般的である理由はいくつかあると思います。
- 研究：STMはホットな研究トピックであり、プログラミング言語の研究者は機能的な言語での作業を好むことがよくあります（それ自体が研究トピックであり、プログラムの動作に関する「証明」を作成するのが簡単です）
- ロックは構成しない：STMは、異なるコンポーネントを構成することで複雑なシステムにスケールアップすると問題が発生し始める並行性へのロックベースのアプローチの代替として見ることができます。これが間違いなくSTMの主な「実用的な」理由です
- STMは不変性によく適合します。不変の構造が大きい場合は、不変のままにしておき、他のスレッドが入ってサブ要素を変更したくないようにします。同様に、上記のデータ構造の不変性を保証できる場合は、STMシステムで「is」を安定した「値」として確実に扱うことができます。
個人的には可変性を許可するClojureのアプローチが好きですが、STMトランザクションに参加する可能性がある厳密に制御された「管理参照」のコンテキストでのみです。言語の他のすべては「純粋に機能的」です。
;; define two accounts as managed references
(def account-a (ref 100))
(def account-b (ref 100))
;; define a transactional "transfer" function
(defn transfer [ref-1 ref-2 amount]
(dosync
(if (>= @ref-1 amount)
(do
(alter ref-1 - amount)
(alter ref-2 + amount))
(throw (Error. "Insufficient balance!")))))
;; make a stranfer
(transfer account-a account-b 75)
;; inspect the accounts
@account-a
=> 25
@account-b
=> 175
上記のコードは完全にトランザクションおよびアトミックであることに注意してください。別のトランザクション内の2つのバランスを読み取る外部オブザーバーは、常に一貫したアトミック状態を確認します。多くのトランザクションエンティティを持つ大規模で複雑なシステムで解決するため。
さらなる啓発のために、Rich HickeyはこのビデオでClojureのSTMを説明する素晴らしい仕事をしています