Clojure には、永続的なデータ構造、ベクトル、マップ、およびセットのいくつかに一時的な類似物があります。ベクトルの場合、永続ベクトルのとに類似したpop!と関数がありますが、 はありません。 conj!popconjpeek!
peek!の効率的な実装を不可能にする技術的な理由はありますか? それとも、一時的なベクトルのほとんどのユースケースでは必要ないのでしょうか? いつでもできる
(defn peek! [tvec] (get tvec (dec (count tvec))))
しかし、組み込みのソリューションがないのは奇妙に思えます。
これは実際には ggroup に最適な設計上の問題ですが、FWIW、私はpeek/peek!を少し前に調査しましたが、提供することは、並列へpeek!の新しいclojure.lang.ITransientStackインターフェイスを作成し、clojure.lang.IPersistentStack一時的なベクトルにそれを実装させるという単純な問題のようです。
私の推測では、そのようなインターフェースがまだ利用可能でない場合 (およびトランジェントによって使用されていない場合) は、おそらく優先順位の問題です。シングル スレッドの高速スタックの実装は、Clojure で の形式で既に利用可能java.util.Stackです。Clojure-in Clojure の開発が進むにつれて、構文上の利便性と永続的なベクトルへのスムーズな変換が実現するでしょう。
(投資した労力に対する見返りが高い場合、Clojure の Java 側の改善は、たとえ最終的な目標が最終的に Java コードベースの関連部分を削除し、Clojure の実装に置き換えることであっても意味があります。期待される見返りが低い場合、プロトコルがより広く使用されるなどを待つ方が理にかなっているかもしれません。トランジェントを処理するために現在利用可能な関数のセットは、Clojure自身のニーズに十分でありpeek!、ggroupで呼び出しがあったかどうかはわかりません-に関しては#clojure、私は 1 つの関連する会話を覚えています -- したがって、リターンはおそらく低いと判断されます... ただし、これを変更するために草の根運動を開始することはできます。:-))