問題タブ [lazy-sequences]

バイナリ ツリーを出力しようとしていますが、Clojure がシーケンスを正しく出力するのに苦労しています。

'(1 2 3)たとえば、ノードのリストがあります。

各反復で、各要素の前後に多数のスペースを含むノードを出力したいと考えています。

すごい、これはうまくいくようです。

それで、私がnodes '(:a :b :c)1行に印刷したいリストを持っているとしましょう。

私はアイテムのリストを持っています。マップを使用して、文字列オブジェクトのリストを取得します。よし、印刷できるぞ！

しかし、これは私にこれを与えます:

そこで、遅延シーケンスを印刷する方法をグーグル検索し、print-strコマンドを使用するようになりました。ドキュメントによると、これは文字列に出力され、返されます。

しかし、これは私にこれを与えます:

変わらない..うーん。どんな助けでも大歓迎です。

カスタム マップ関数を再実装しようとしていますが、奇妙な方法で動作します。なぜそれが起こるのか説明できますか？

最初のテイクは期待どおりに動作しますが、2 番目のテイクでは次のエラーが発生します (すべてのシーケンスを評価しているように見えます)。

現在、レイジー seq について学んでいますが、それらは通常、 を使用せずに再帰を伴うことに気付きましたrecur。たとえば、次の実装がありiterateます。

を使用せずに再帰するrecurと、呼び出しごとに新しいスタック フレームが作成され、十分な回数反復するとスタック オーバーフローが発生する可能性があるという印象を受けました。

lazy-seqスタックフレームをむさぼり食いますか? そうでない場合、どのようにそれを回避しますか?

アイテムのソースがあり、キー関数の同じ値を持つアイテムの実行を個別に処理したいと考えています。Python では、これは次のようになります。

このソリューションは完全に怠惰です。つまりprocess、全体の内容を保存しようとしない場合part、コードはO(1)メモリ内で実行されます。

Clojure ソリューション

怠惰ではありません。各部分を完全に実現します。問題は、src同じ値を持つアイテムが非常に長く続く可能性があり、key-fnそれらを認識すると OOM につながる可能性があることです。

次の関数（投稿内の名前の一貫性のためにわずかに変更されています）が十分に怠惰であると主張されているこの議論を見つけました

ただし、OOM に悩まされない理由がわかりません。コンス セルの両方の部分が への参照を保持しているsため、 をprocess消費partしている間sは実現されていますが、ガベージ コレクションは行われていません。drop-whileトラバース時のみGC対象となりますpart。

だから、私の質問は次のとおりです。

1. lazy-partition-by怠け者ではないというのは正しいですか？
2. 次のものを実現し始めるpartition-byまでに前のものへの参照を保持していなければ、メモリ要件が保証された実装はありますか?part

編集: これは Haskell での十分に怠惰な実装です:

span実装からわかるようにpart、rest暗黙的に状態を共有します。このメソッドを Clojure に翻訳できないかと考えています。