私は「モデル」 (つまり、UML などの何らかのセマンティクスを持つボックスと線のコレクションであり、その詳細はここでは関係ありません) 用のグラフィカル エディターを作成しています。したがって、モデルを表すデータ構造と、ダイアグラムを編集するとモデルに対応する変更が生じるダイアグラムが必要です。たとえば、モデル要素の属性にテキストが含まれていて、ダイアグラムでテキストを編集する場合、モデル要素を更新する必要があります。
モデルはおそらくツリーとして表されますが、ダイアグラム エディターにはモデルの表現についてできるだけ知らないようにしたいと考えています。(私はダイアグラムフレームワークを使用しているので、任意の情報をグラフィック要素に関連付けるのは簡単です)。それがどうあるべきかを理解できれば、インターフェイスをエンコードする「モデル」クラスがおそらくあるでしょう。
これを命令型言語で行う場合は、簡単です。ダイアグラム内のグラフィカル要素からモデル要素への参照を取得するだけです。理論的には、大量の IORef のコレクションからモデルを構築することでこれを行うことができますが、それは Haskell で Java プログラムを作成することになります。
明らかに、各グラフィック要素には、モデルの更新を可能にする何らかの種類の Cookie が関連付けられています。簡単な答えの 1 つは、各モデル要素に一意の識別子を与え、モデルを Data.Map ルックアップ テーブルに格納することです。ただし、2 つのモデル要素が同じ識別子を取得しないようにするためには、かなりの簿記が必要です。また、「文字列型」のソリューションとしても印象的です。オブジェクトが削除されたが、他の場所でぶら下がっている参照があり、型のモデルの内部構造について何かを言うのが難しい場合を処理する必要があります。
一方、複数の穴を備えたジッパーと明確なトランザクション共有を備えたカーソルに関するOleg の著作は、私が理解できれば、より良い選択肢のように思えます。リスト ジッパーとツリー ジッパーの基本的な考え方と、データ構造の差別化について理解しました。ダイアグラム内のすべての要素がモデルのジッパーにカーソルを保持することは可能でしょうか? 変更が行われた場合、それを他のすべてのカーソルにコミットできるようにするには? ツリー操作 (サブツリーをある場所から別の場所に移動するなど) を含めますか?
区切られた継続に関するある種のチュートリアルと、それらがオレグのマルチカーソルジッパーをどのように機能させるかについての説明があれば、この時点で特に役立ちます。それはオレグの投稿よりも少し急ではありませんか?