問題タブ [referential-transparency]

純粋関数:

1. 特定の入力に対して常に同じ結果を返す
2. 副作用を生じさせない

これにより、プログラムの動作を変更せずに式を値に置き換えることができる参照透過性が得られます。

これは、プログラムの実行環境でエンティティの破壊的な変更 (更新) を除外する場合、プログラムは純粋に機能していると言えることを示しています。

ソフトウェア トランザクション メモリを見ると、同時実行コンピューティングで共有メモリへのアクセスを制御するためのデータベース トランザクションに類似した同時実行制御メカニズムが見られます。しかし、それ自体で特に機能するものは何もありません。

私の質問は、Clojure の STM を「機能的」と見なすことができるかということです。

Erlang での単一代入はどのようにしてより読みやすいコード (参照の透過性) につながりますか?

Haskell で記述されたプログラミング言語インタープリターに IO 関数を追加するには、基本的に 2 つのオプションがあります。

• インタプリタ全体を IO モナド内で実行するように変更します
• 解釈されたプログラムによって呼び出すことができる実行時関数を使用しますunsafePerformIO。

前者は私には悪い考えのように感じます。これは、プログラムのほぼすべての場所に到達することにより、 純度の利点を効果的に無効にします。IO私も現在頻繁に使用しSTており、これを達成するには大量のプログラムを変更する必要があります.STIO

後者は私を緊張させます-関数名が示すように、安全ではありませんが、この状況では正当化される可能性があると思います. 特に：

• この変更によって変更されるコードの量はごくわずかです。
• IO が実行される可能性のあるseqポイントは、解釈された式の評価中に at コントロール ポイントを使用することによって、既に明示的に順序付けられています。
• おそらくもっと重要なことは、IO アクションによって返される値は、コードの解釈されたセクション内でのみ使用されることです。ここでは、操作カウンターがスレッド化されるため、同じ引数でインタープリターを複数回呼び出すことができないという事実によって、参照の透過性を保証できます。システム全体が同じ変更の一部であり、を使用するすべての関数に常に一意の値が渡されますunsafePerformIO。

この状況で、使用しない正当な理由はありますunsafePerformIOか?

アップデート

インタプリタで純粋さを保ちたい理由を尋ねられました。いくつかの理由がありますが、おそらく最も差し迫ったのは、後でこの言語用のコンパイラを構築するつもりであり、言語には、コンパイラにインタープリターを含める必要があるさまざまなメタプログラミング手法が含まれるということですが、私はそうしたいと考えています。コンパイル結果の純度を保証できます。言語にはこの目的のための純粋なサブセットがあり、そのサブセットを実行するときにインタープリターが純粋であることを望みます。

これは哲学に近いかもしれませんが、質問するのに適切な場所だと思いました.

ID のリストを作成する関数があるとします。これらの識別子はアプリケーションの内部でのみ使用されるため、ここで ES2015 を使用してもかまいませんSymbol()。

私の問題は、技術的には、シンボルを要求すると、JS ランタイムが一意の識別子 (乱数? メモリ アドレス? 不明) を作成し、衝突を防ぐためにグローバル状態にアクセスする必要があると思います。よくわからないのは、「技術的に」という言葉のせいです。API が提示する数学的抽象化を破るのにこれが十分であるかどうかは、(やはり哲学的な観点から)わかりません。

tl;dr:これが例です--

この関数は純粋ですか?

だから私はFPを学ぼうとしていて、参照透過性と副作用について頭を悩ませようとしています。

型システムですべての効果を明示的にすることが、参照透過性を保証する唯一の方法であることを学びました。

「ほぼ関数型プログラミング」という考えは実現不可能です。暗黙的な副作用を部分的に取り除くだけでは、命令型プログラミング言語をより安全にすることは不可能です。多くの場合、1 種類のエフェクトを残すだけで、削除しようとしたエフェクトそのものをシミュレートするのに十分です。一方、純粋な言語で効果を「忘れる」ことを許可すると、それ自体が混乱を引き起こします。

残念ながら、ゴールデン ミドルは存在せず、古典的な二分法に直面しています。排除されたミドルの呪いは、次のいずれかの選択を提示します。依然として根本的に効果的です。または (b) 型システムですべての効果を明示し、実用的にすることで純粋性を完全に受け入れる -ソース

また、Scala や F# などの非純粋な FP 言語では参照透過性を保証できないことも学びました。

参照透過性を強制する機能は、Java と相互運用可能なクラス/オブジェクト システムを持つという Scala の目標とほとんど相容れません。-ソース

そして、非純粋な FP では、参照透過性を確保するのはプログラマ次第です。

ML、Scala、F# などの非純粋な言語では、プログラマーが参照透過性を確保する必要があります。もちろん、Clojure や Scheme などの動的型付け言語では、参照透過性を強制する静的型システムはありません。-ソース

.Net の経験があるので F# に興味があります。次の質問は次のとおりです。

F# コンパイラによって適用されない場合、F# アプリケーションで参照透過性を保証するにはどうすればよいですか?

このコードを投稿しました：

のバージョンunsafeThawしか解凍していないので、ここで安全に使用できるというのが私の推論でした。しかし、タプルのボックス化されていないベクトル (ここでのインデックスと値のペアのように) は、実際には 2 つのボックス化されていないベクトル (1 つはインデックス用、もう 1 つは値用) として格納されていることに気付きました。したがって、実際には新しい値ベクトルをまったく生成せず、それをインデックス ベクトルと結合するだけである可能性が高いと思われます。この場合、-modifyingは台無しになる可能性があります。indexedxsindexedSTxsixs

ただし、テストすると、これは発生しないようです。これに頼ることができますか、それともより適切に使用する必要がありますthawか?

私は現在、関数型プログラミングに関するプレゼンテーションに取り組んでおり、次の問題に遭遇しました。

関数型プログラミングは、「何」を「どのように」から分離するか、より正確には、計算の宣言をその解釈から分離することを意図しています。これが、このパラダイムの主な焦点の 1 つは、計算がどのように実行されるかについて何の仮定もせずに、構成可能なデータ構造を使用して計算を表すことである理由です。例えば：

副作用は計算の実行中にのみ実行され、宣言中には実行されないため、これは理にかなっているようです。問題は、Scala では、多くのデータ構造がこの規則に違反しているように見えることです。

についても同じFutures:

それで、私は今疑問に思っていますが、参照透過性はTry本当にありFutureますか? Successそうでない場合、およびに依存せずにエラーケースをどのように処理する必要がありFailureますか?