問題タブ [unsafe-perform-io]

この疑似コード ブロックでは:

安全に使用できunsafeIOToSTMますか? ドキュメントは言う：

• STM 実装はトランザクションを複数回実行することが多いため、IO に副作用がある場合は、これに備える必要があります。

  基本的に、トランザクションが失敗した場合、他のスレッドが原因でwroteValueToLocalStorageあり、トランザクションが再試行されると、データベースから再度フェッチする代わりに、保存された値が返されます。

• STM 実装は、無効であることがわかっているトランザクションを中止し、再起動する必要があります。これは unsafeIOToSTM の途中で発生する可能性があるため、解放が必要なリソースを取得しないようにしてください (トランザクションを中止する場合、例外ハンドラーは無視されます)。これには、たとえばハンドルを使用した IO の実行が含まれます。これを間違えると、ランダムなデッドロックが発生する可能性があります。

  これが一番気になります。論理的にfetchValueFromDatabaseは、新しい接続が開かれない場合 (つまり、既存の接続が使用されている場合) は、すべて問題ないはずです。私が見逃している他の落とし穴はありますか？

• トランザクションは、IO の実行時にメモリの一貫性のないビューを認識した可能性があります。プログラム全体で真であると期待される不変条件は、トランザクションの実装方法により、トランザクション内では真ではない場合があります。通常、これはプログラマーには表示されませんが、unsafeIOToSTM を使用すると公開される可能性があります。

  key単一の値であり、破る不変条件はありません。

私は持っている

これは私には合法的に使用されているように見えunsafePerformIOます。しかし、私はそれを回避する方法を知ることに非常に興味があります! この用途のパターンはすでにありますか?

私はこのようなことをしようとしています:

基本的に、これはリストを反復処理し、各要素を別のものにマップし、プロセスで内部のプライベート状態を使用する計算です。特定iniの 、upd、およびfin私は C ライブラリから来ていることを念頭に置いていますが、それらは単に新しい状態を割り当て、唯一の副作用が状態を変更する計算を実行し、状態の割り当てを解除するという点で「うまく動作する」ことが保証されています. これは、安全に前に置いunsafePerformIOて純粋な関数を取得できることを意味すると思います。

今、私は同じことをしたいと思いますが、conduit(または、実際には他のストリーミング ライブラリ) を使用します。ただし、計算は本質的に効果がないため、コンジットを純粋にしたいと思います。

またはさらに良い：

(要素が純粋であるという理由だけで、このトリックは単純なリストで非常にうまく機能するように見えるため、後者は意味をなさないのではないかと思います。)

理想的には、計算には状態が必要であり、外部呼び出しを行うという事実をユーザーから完全に隠し、それが単なる a scanl(またはmapAccumとconduit呼ばれる) のようなものであると偽る必要があります。

これは可能ですか？conduit(または他のストリーミング ライブラリ)でこれを行うにはどうすればよいですか?