問題タブ [alternative-functor]

_{これは問題を探す解決策かもしれません...もしそうなら、私はあなたの耽溺をお願いします！}

可能な実装：

解釈は次のようになります。成功した計算が与えられた場合、それを失敗したものにします。失敗した計算が与えられたら、それを成功させます。よくわかりませんが、これはMonadPlusとは逆のようです...本当に目を細めている場合。???

この概念の標準の型クラスまたはその他の実装はありますか？もしあれば、基礎となる数学はどのように見えるでしょうか（つまり、これは半群、ループなどです）？

クラスの名前とパーサーでの使用法から、そしてMaybe私はそれが動作するのはから最初の空でない入力を選択することだと思いましたa <|> b <|> c。だから私は入力のためにそれを期待しました

空でない最初のリストを返します。つまり、次のようになります。

しかし、実際にはすべてを連結して、次のように生成します。

だから私はそのような実装の背後にある理由は何ですか？それは実際に正しいですか？

http://hackage.haskell.org/packages/archive/base/latest/doc/html/Control-Applicative.html#t:Alternative

PS私が期待したことを実行する標準機能はありますAlternativeか？

私が自分で一緒にジグザグしているものの多くは、実際には私が知らなかった標準の実装を持っているので、誰かが以前にこのタイプのものが使用されたのを見たことがあると言うことができるかどうか興味がありました：

これはモナディック関数を取り、代替によって述語が選択されるまでそれをフォールドし、その後、述語の結果を返します。

名前はプレリュードの衝突であることに気づきました。おそらく別の名前を付けますが、私が知らない標準ライブラリに同様の機能がすでにあるかどうかを最初に確認したいと思いました。

また、私が書いた構図の代替案が他の場所で定義されているのか、それともこの機能のいずれかが最初から誤った方向に進んでいるように見えるのか、興味があります。しかし、私の質問の核心は、これは他の場所で実装されているのか、それとも他の場所で非常によく似たものであるのかということです。

このパーサータイプがあるとしましょう：

そして、このアトミック パーサー ユニット:

パーサーは、次の 3 つのインターフェイスを実装します。

私が理解しているように、より高いレベルの抽象化にポップアップしsatisfy、アプリケーション インターフェイスを使用して連鎖することにより、より複雑なパーサーを構築できるようになりました。例:

これはすばらしいことですが、小文字に遭遇するまでパーサーがストリーム内のすべての大文字を解析するように計算を構築したい場合はどうすればよいでしょうか? 使用事例：

この決定されない長さの概念をどのように表現すればよいでしょうか?

ZipListFunctorとApplicativeインスタンス ( Control.Applicative ) が付属していますが、なぜAlternativeでしょうか?

• いい例はありませんか？
• 以下で提案されているものはどうですか？
  • 欠陥がありますか？
  • 無駄ですか？
  • 他の合理的な可能性 ( Bool2 つの方法でモノイドになることができるなど) はありますか?したがって、どちらもインスタンスであってはなりませんか?

「インスタンスの代替 ZipList」(最初にコードを見つけるための引用符付き) を検索したところ、ライブラリ、いくつかのチュートリアル、講義ノートしか見つかりませんでしたが、実際のインスタンスは見つかりませんでした。

マット・フェンウィックはZipList A、 がモノイドになるのは が の場合だけだと言いましたA(こちらを参照)。ただし、要素の型に関係なく、リストはモノイドです。

同じ質問に対するAndrewCによるこの他の回答Alternativeでは、インスタンスがどのように見えるかについて説明しています。彼は言う

には 2 つの賢明な選択がありますZip [1,3,4] <|> Zip [10,20,30,40]。

1. Zip [1,3,4]それは最初だから - 多分と一致する
2. Zip [10,20,30,40]最長であるため -Zip []破棄されることと一致します

Zip基本的にはどこですかZipList。

答えは であるべきだと思いますZip [1,3,4,40]。インスタンスを見てみましょう:

Zip a型引数を知らずに生成できるaのはだけZip [] :: Zip aなので、 の選択肢はほとんどありませんempty。空リストがモノイドの中立要素である場合、リスト連結を使用したくなるかもしれません。ただし、のせいでgoはありません。最初の引数リストの 1 つのエントリを使用するたびに、2 番目の引数リストからも 1 つ削除します。したがって、一種のオーバーレイがあります。左の引数リストは、右の引数リストの先頭 (またはそのすべて) を隠します。(++)drop 1

ziplists の背後にある 1 つの直感はプロセスです。結果の有限または無限のストリームです。Applicativezip するとき、インスタンスによって反映されるストリームを結合します。リストの最後に到達すると、ストリームはそれ以上の要素を生成しません。ここでAlternativeインスタンスが役に立ちます。デフォルトのプロセスが終了するとすぐに引き継ぐ、同時置換 (実際には代替) を指定できます。

たとえばfmap Just foo <|> pure Nothing、ziplist のすべての要素をfooaにラップするように記述してJust、Nothingその後に進むことができます。結果の ziplist は無限であり、すべての (実際の) 値が使い果たされるとデフォルト値に戻ります。Zipこれはもちろん、コンストラクター内に無限リストを追加することにより、手動で行うことができます。それでも、上記はより洗練されており、コンストラクターの知識を前提としないため、コードの再利用性が高くなります。

要素の型に関する仮定は必要ありません (モノイド自体であるなど)。同時に、定義は自明ではありません ((<|>) = constそうであるように)。最初の引数でのパターン マッチングによってリスト構造を利用します。

上記の の定義<|>は連想的であり、空のリストは実際には空の要素です。我々は持っています

したがって、求めることができるすべての法則が満たされます (これは、リストの連結には当てはまりません)。

このインスタンスは、次のものと一致していますMaybe。選択は左に偏っていますが、左の引数が値を生成できない場合、右の引数が引き継がれます。機能

は選択肢の射 (意味psi x <|> psi y = psi (x <|> y)とpsi x <*> psi y = psi (x <*> y)) です。

編集：私が推測するsome/メソッドについてmany

Applicative functor は、効果的なコンテキストで関数を適用できることから、Haskeller の間でよく知られ、愛されています。

Applicative圏論の用語では、 の方法が次のことを示すことができます。

Functor fは、操作で a を持つことと同等です。

inを指定された値にpure置き換えるだけで、関数と引数をタプルに押しつぶしてから、適切なアプリケーション関数をその上にマップするという考えです。()unit(<*>)

さらに、この対応は法則をとApplicativeについての自然なモノイド的な法則に変えるので、実際、適用可能な関手は、まさに圏論者が緩いモノイド関手と呼ぶものです (緩いのは単に自然な変換であって同型ではないからです)。unit(**)(**)

よしよし、よかった。これだけはよく知られています。しかし、これは緩いモノイド関手の 1 つのファミリにすぎません。積のモノイド構造を尊重するものです。緩いモノイド ファンクターには、ソースとデスティネーションのモノイド構造の 2 つの選択肢が含まれます。積を和に変換すると、次のようになります。

合計を他のモノイド構造に変換することは、一意に決定されることによって面白くないように思われるunit :: Void -> f Voidため、実際には半群が多くなっています。それでも：

• 上記のような他の緩いモノイド関手は研究されているか、または有用ですか?
• そのような彼らのためのきちんとした代替プレゼンテーションはありApplicativeますか?

Haskell のドキュメンテーションを読むのは、私にとっていつも少し苦痛です。なぜなら、関数について得られるすべての情報は、多くの場合、単なるものに過ぎないからf a -> f [a]です。

関数の場合と同様です<|>。

私に与えられた(<|>) :: f a -> f a -> f aのはこれだけです：そしてそれは「連想バイナリ操作」です...

調べControl.Applicativeてみると、実装によっては一見関係のないことをしていることがわかります。

わかりましたので、左がない場合は右を返し、そうでない場合は左を返します..これは、 「左または右」演算子である|と私に信じさせます。|"

ここを除いて、リストの連結演算子を呼び出すだけです...私の考えを打ち破る...

では、その機能とは一体何なのでしょうか？その用途は何ですか？それは物事の壮大な計画のどこに当てはまりますか?

次の型シグネチャを検討してください。

ここで、 からの型Fooへの自然な変換を示します。optparse-applicativeParser

（わかりました、それは少し役に立ちませんが、議論には役立ちます）。

今、私Barは自由な代替ファンクターであるとしFooます:

これがフリー ファンクターであることを考えると、 からへmkParserの自然な変換に移行できるはずです。BarParser

そして確かに、これは機能し、私にParser戻ってきます。ただし、それを多くのことをしようとすると無限ループになるため、これはかなり役に立たないものです。たとえば、それを説明しようとすると：

そして、中断されるまでハングアップします。

この理由は、 andの定義をoptparse-applicative ごまかすためのようです: カバーの下でモナド構文解析を使用します。manysome

ここで何か間違ったことをしていますか？これを考えると、この方法でパーサーを構築する方法がわかりません。何か案は？