Это действительно вопрос дизайна, лучше всего направленный в ggroup, но FWIW, я действительно исследовал peek / peek! некоторое время назад, и предоставление peek! кажется простым делом создания нового интерфейса clojure.lang.ITransientStack дляпараллельный clojure.lang.IPersistentStack и наличие переходных векторов, реализующих его.
Я предполагаю, что если такой интерфейс еще не доступен (и используется переходными процессами), это, вероятно, вопрос приоритетов.Однопоточная реализация быстрого стека уже доступна в Clojure в виде java.util.Stack, поэтому мы не пропускаем такое количество функций;синтаксическое удобство и плавное преобразование в постоянные векторы, вероятно, будут достигнуты благодаря успеху Clojure-in-Clojure.
(Там, где отдача от вложенных усилий высока, улучшения в Java-стороне Clojure имеют смысл, даже есликонечная цель в конечном итоге состоит в том, чтобы отбросить релевантную часть кодовой базы Java и заменить ее реализацией в Clojure. Там, где ожидаемые результаты ниже, может иметь больше смысла ждать более широкого использования протоколов и т. д. Доступный в настоящее время наборфункций для обработки переходных процессов достаточно для собственных нужд Clojure, и я не уверен, что когда-либо был вызван peek! в ggroup - что касается #clojure, я помню один соответствующий разговор - так что возвращение, вероятно, считается низким ..Вы можете начать массовые движения, чтобы изменить это.: -))