問題タブ [ioref]

IO モナドに固有の次の関数を作成しました。

使用例:

" hello" を 1 回出力します。

（IOだけでなく）できるだけ多くのケースで機能するようにしたいと思います（ペットピーブ）。

ハックでstaterefを見つけたので、コードは次のようになります。

stateref の代替手段や、私が行ったよりも良い使用方法はありますか?

One thing that has always confused me is whether or not it's an okay time to use an IORef. Are there any guidelines that should be followed when deciding whether or not to use an IORef for a task? When is a good time to use the State monad over an IORef?

サンプルコードを見つけて、少し変更しました

実行されるたびに、1、2、3、3 などを返します。

しかし、私はそれを

その後、実行するたびに0になります。

なぜこれが起こっているのですか?それを修正するにはどうすればよいですか?

HaskellのIORefタイプとMVarタイプの基本的な違いを理解するのに少し問題があります。誰かがこれを手伝ってくれますか？それらは同じ問題を解決するように見えます。MVarはマルチスレッドを対象としているようですが、IORefにはatomicModifyIORef関数があります。

ありがとう！

私は48 時間以内に自分でスキームを書く(私は約 85 時間までです) に取り組んでおり、変数と代入の追加に関する部分に到達しました。この章には大きな概念上のジャンプがあります。最終的な解決策に直接ジャンプするのではなく、その間に適切なリファクタリングを行って 2 つのステップで実行されていればよかったのにと思います。とにかく…</p>

同じ目的を果たしているように見える多くの異なるクラスで迷子になりました: State、ST、IORef、およびMVar. 最初の 3 つはテキストで言及されていますが、最後の 3 つは、最初の 3 つに関する多くの StackOverflow の質問に対する好まれる回答のようです。それらはすべて、連続する呼び出しの間に状態を保持しているようです。

これらはそれぞれどのようなもので、どのように互いに異なるのでしょうか?

特に、次の文は意味がありません。

代わりに、状態スレッドと呼ばれる機能を使用して、Haskell に集約状態を管理させます。これにより、変数を取得または設定する関数を使用して、他のプログラミング言語と同じように変更可能な変数を扱うことができます。

と

IORef モジュールを使用すると、IO モナド内でステートフル変数を使用できます。

これらすべてが行をtype ENV = IORef [(String, IORef LispVal)]混乱させます-なぜ2番目なのIORefですか? type ENV = State [(String, LispVal)]代わりに書くと何が壊れますか？

IORef を読み取り、いくつかの条件と計算に基づいて新しい値を作成するコードがあります。次に、その IORef に新しい値を書き込みます。しかし、まったく変更されていない可能性があります。新しい値は古い値と同じかもしれません。

IORef を書き込む前に値が異なるかどうかを確認するか、IORef を書き込むだけにするかに関する考慮事項は何ですか?

writeIORef は、設定前に値が変更されているかどうかを確認しますか?

最初に確認することで、書き込みを回避し、パフォーマンスを少し節約できますか?

'dである長期実行プロセスがありforkIO、ピクセルカラー値を生成します。

（ここで、Color3つの値を保持しDoubleます）。

予想どおり、の「反対側」で読み取った場合、IORef保存された値は単なるサンクであるため、メインプロセスをブロックします。

通常の形式で値を完全に評価する必要があることはわかってい[[Color]]ますが、それを実現するには2つの方法があるようです。さらに、どちらをコードに組み込むかがわかりません。

どうすればいいですか？rnf、、deepSeqまたはその他のスレッド戦略を使用しますか？これらの1つが優先され、他は非推奨になりますか？そして、それは私のコードにどのように適合しますか？

（PSは、画像を色のリストのリストとして保存するのはばかげているという事実を無視してください。これは、コードの単純化されたバージョンにすぎません）。

最終的に IORefs が不要になるように、これをどのようにリファクタリングできますか?

重要な要素としてIORefを含むデータ型があります。showこれは、型クラスのメンバーにするためのクリーンな方法がないことを意味します。printこのタイプのIOモナドに関数があるので、これはそれほど悪くはありません。しかし、GHCiでは、これらのいずれかを返すたびに、表示できないというエラーが発生するという点で煩わしいです。

とにかくIOモナドで動作するGHCiに、IOアクションを使用して結果を表示させる方法はありますか？そうでない場合、書くことへの悪影響はありますshow a = unsafePerformIO $ print aか？

セットアップ:

仮想システムでシミュレートされたオブジェクトの状態を表すさまざまなデータ構造のコレクションがいくつかあります。また、これらのオブジェクトを変換する (つまり、元のオブジェクトと 0 個以上のパラメーターに基づいてオブジェクトの新しいコピーを作成する) 関数もいくつかあります。

目標は、ユーザーが (シミュレーションのルール内で) 変換を適用するオブジェクトを選択し、それらの関数をそれらのオブジェクトに適用し、古いオブジェクトを新しいオブジェクトに置き換えることでコレクションを更新できるようにすることです。

小さな変換を大きな変換に組み合わせることで、このタイプの関数を構築できるようにしたいと考えています。次に、この結合関数を評価します。

質問:

これを可能にするためにプログラムを構成するにはどうすればよいですか?

このようなトランザクションを構築するには、どのようなコンビネーターを使用すればよいでしょうか?

アイデア:

1. すべてのコレクションを 1 つの巨大な構造に入れ、この構造をあちこちに渡します。
2. 基本的に同じことを達成するために状態モナドを使用する
3. IORef (または MVar のようなより強力な従兄弟の 1 つ) を使用して、IO アクションを構築します。
4. 関数型リアクティブ プログラミング フレームワークを使用する

1 と 2 は、特に最終的にコレクションの一部をデータベースに移動することを想定している場合、多くの荷物を持ち歩いているように見えます。(くそIOモナド)

3 はうまく機能しているように見えますが、OOP を再作成するように見え始めます。また、どのレベルで IORef を使用すればよいかもわかりません。(例:IORef (Collection Obj)またはCollection (IORef Obj)またはdata Obj {field::IORef(Type)} )

4 はスタイルが最も機能的であると感じますが、表現力の点であまり見返りがなく、多くのコードの複雑さを生み出しているようにも見えます.

例

私はウェブストアフロントを持っています。私は、（とりわけ）在庫数と価格を含む製品のコレクションを維持しています。また、ストアの信用を持つユーザーのコレクションもあります。

ユーザーがやって来て、購入する 3 つの製品を選択し、ストア クレジットを使用してチェックアウトします。3 つの製品の在庫を減らした新しい製品コレクションを作成し、ユーザー アカウントが引き落とされた新しいユーザー コレクションを作成する必要があります。

これは、次のことを意味します。

しかし、その後、生活はより複雑になり、税金に対処する必要があります。

そして、注文を配送キューに確実に追加する必要があります。

などなど…

私が書きたいのは次のようなものです

しかし、タイプチェッカーは私に夢中になったでしょう。checkoutまたはapplyUserCredit関数がモジュール化され、抽象化されたままになるように、このストアをどのように構造化すればよいでしょうか? この問題を抱えているのは私だけではありませんよね?