問題タブ [scalaz7]

現在、このクラスを使用してTree、データベース クエリからツリー構造を構築しようとしています。その後、jsonオブジェクトに変換したい（playframework apiを使用）。

クラスのいくつかの例またはもう少しドキュメントはTree素晴らしいでしょう. drawanddrawTreeメソッドの周りに頭を悩ませることはできません。これは同様のことを行う可能性があります。

例

これにより、次のようなjsonツリーが生成されます

makePomsbt で実行すると、次のようになります。

正しい除外が生成されるように、この問題を修正する最も簡単な方法は何ですか?

以下は機能しません- これは scalaz の除外規則に違反しています - おそらく、scalaz 7 は複数の jar で構成されているからだと思います:

と

Scalaz 7.x で定義されscala.collection.Traversable[A]た a から a への暗黙の変換はどこにありますか? scalaz.Foldable[A]標準インポート

含まれません。

以前は でimplicit def TraversableFoldable[]...定義されていましscalaz/Foldable.scalaたが、

関連する Implicit は で定義されscalaz/Foldable.scalaていましたが、 に移動されました。

scalaz.std.traversable存在しませんが。おそらくこれは偶然の省略ですか？

FWIWscalaz.std.listは標準インポートに含まれているため、 a は にList[A]変換されFoldable[A]ます。 scalaz.std.iterableは標準のインポートに含まれていないため、明示的にインポートする必要があります。暗黙的に変換Iterable[A]するには。Foldable[A]

一定のスタックとヒープ空間で State モナドで折り畳みを実行することは可能ですか? または、別の機能的手法が私の問題により適していますか?

次のセクションでは、問題と動機付けとなるユース ケースについて説明します。私は Scala を使用していますが、Haskell でのソリューションも歓迎します。

Stateモナドのフォールドがヒープを埋める

Scalaz 7 を仮定します。 State モナドのモナド折り畳みを考えます。スタック オーバーフローを避けるために、フォールドをトランポリンします。

大規模なコレクションのcol場合、これでヒープがいっぱいになります。

フォールド中に、コレクション (パラメーター) 内の値ごとにクロージャー (State mobit) が作成されx: R、ヒープがいっぱいになると思います。が実行されるまで、これらはどれも評価できずrun 0、初期状態が提供されます。

この O(n) ヒープの使用を回避できますか?

より具体的には、後で評価するためにクロージャをネストするのではなく、State モナドが各バインド中に実行できるように、フォールドの前に初期状態を提供できますか?

それとも、State モナドの後に遅延実行されるように折り畳みを構築できrunますか? このようにして、次のx: Rクロージャーは、前のクロージャーが評価されてガベージ コレクションに適したものになるまで作成されません。

それとも、この種の作業のためのより優れた機能パラダイムはありますか?

適用例

しかし、おそらく私は仕事に間違ったツールを使用しています。ユースケースの例の進化は次のとおりです。私はここで間違った道をさまよっていますか？

リザーバー サンプリング、つまり、k大きすぎてメモリに収まらないコレクションから均一なランダム アイテムを1 回のパスで選択することを検討してください。Scala では、そのような関数は次のようになります。

そして、タイプにポンピングされた場合、TraversableOnceこのように使用できます

によって行われる作業sampleは、基本的に次のfoldとおりです。

ただし、updateステートフルです。nそれは、すでに見たアイテムの数に依存します。(これは RNG にも依存しますが、簡単にするために、それはグローバルでステートフルであると仮定します。処理に使用される手法nは自明に拡張されます。) では、この状態をどのように処理するのでしょうか?

不純なソリューションはシンプルで、一定のスタックとヒープで実行されます。

しかし、純粋に機能的なソリューションはどうでしょうか? update追加のパラメーターとして取りn、更新されたサンプルと共に新しい値を返す必要があります。n暗黙的な状態にフォールド アキュムレータを含めることができます。

しかし、それは意図をあいまいにします。サンプルベクトルを累積するだけです。この問題は、State モナドとモナドの左折畳みのために用意されているようです。もう一度試してみましょう。

これらのインポートで Scalaz 7 を使用します

Iterable[A]Scalaz は a のモナド畳み込みをサポートしていないため、an を操作しTraversableます。

sample現在定義されています

更新はどこにありますか

残念ながら、これは大規模なコレクションのスタックを吹き飛ばします。

それではトランポリンしましょう。sample今でしょ

更新はどこにありますか

これにより、スタック オーバーフローが修正されますが、非常に大きなコレクション (または非常に小さなヒープ) のヒープは依然として吹き飛ばされます。コレクション内の値ごとに 1 つの匿名関数がフォールド中に作成され (各パラメーターを閉じると思いx: Aます)、トランポリンが実行される前にヒープを消費します。(FWIW、State バージョンにもこの問題があります。スタック オーバーフローは、小さなコレクションで最初に表面化するだけです。)

ここでの問題は、選言\/[A, B]には 2 つのジェネリックがあるため、モナドではないことです。タイプエイリアスを作成するとき

左辺を固定してモナドを持っているので、それは成功します。最も外側の型が Disjunction の場合、型のエイリアシングに頼らずに Monad Transformer を機能させるにはどうすればよいですか?

scalaz-stream を使用して、コストのかかる操作でデータのストリームを処理しようとしています※。

※はい、はい、副作用のあるコードを混在させることは、関数型プログラミング スタイルとしてよくないことだとわかっています。print ステートメントは、高価な() が呼び出された回数を追跡するためのものです。)

コストのかかる操作にデータを渡す前に、データをチャンクに分割する必要があります。

次に、コストのかかる操作をチャンクのストリームにマップします。

これを実行すると、expected() が予想される回数だけ呼び出されます。

ただし、zipWithIndex への呼び出しをチェーンすると、expensive() が何度も呼び出されます。

これはバグですか？それが望ましい動作である場合、誰かが理由を説明できますか? cost() に長い時間がかかる場合、呼び出し回数が少ない結果を好む理由がわかります。

より多くの例を含む要点は次のとおりです: https://gist.github.com/underspecified/11279251

暗黙の from toがある場合、暗黙の from AtoBを自動取得するにはどうすれF[A]ばよいF[B]ですか?

たとえば、暗黙のfromを再利用するimplicit toInt[A](l: List[A]) = l.size暗黙のfrom (List[A], Int)toが必要な場合。それはScalaでも可能ですか？(Int, Int)toInt

Web アプリケーションでは、さまざまな方法で失敗するか、最終的に成功するアクションがあります。

このコンテキストでは、成功と失敗は SimpleResult のサブクラス (HTTP 応答を表す) によって表されます。

scalaz / でモナド演算を使用して、アルゴリズムを次のようにエンコードします。

したがって、これは最終的に になり、SimpleResult \/ SimpleResult これを書く必要があります:

選言から結果を抽出しますが、これはかなり醜いと思います。

そのような「明らかに単純化可能な構造」を捉える抽象化はありますか? それとも、選言はその問題の正しい抽象化ではありませんか?