タグ付けされた質問 「monad」

特にデータアクセスのコンテキストで、Interpreterを使用してFree Monadについて話している人々を見てきました。このパターンは何ですか？いつ使用したいですか？どのように機能し、どのように実装しますか？ （このような投稿から）私はそれがモデルをデータアクセスから分離することだと理解しています。よく知られているリポジトリパターンとの違いは何ですか？彼らは同じ動機を持っているように見えます。

95 design-patterns  functional-programming  haskell  dsl  monad 

IOHaskellではモナドは、多くの場合、状態は世界でStateモナドとして説明します。したがって、IO aモナド型の値はのようなものと見なされますworldState -> (a, worldState)。 しばらく前に、私はこの見解を批判し、それが正しくない理由をいくつか示した記事（またはブログ/メーリングリストの投稿）を読みました。しかし、記事も理由も思い出せません。誰もが知っていますか？ 編集：記事は失われたようですので、ここからさまざまな議論を集めましょう。 私は物事をより面白くするための賞金を始めています。 編集：私が探していた記事は、厄介な部隊への取り組みです：サイモンペイトンジョーンズによるHaskellでのモナド入力/出力、同時実行、例外、および外国語呼び出し。（TacTicsの回答に感謝します。）

46 functional-programming  haskell  io  monad 

例外に対するMaybe モナドの利点は何でしょうか？構文のMaybe明示的な（そしてかなりスペースを消費する）方法のように見えtry..catchます。 更新 Haskellについては意図的に言及していないことに注意してください。

34 language-agnostic  functional-programming  exceptions  exception-handling  monad 

Haskellの学習中に、モナドとは何か、Haskellでモナドが重要である理由を説明しようとする多くのチュートリアルに直面しました。それぞれが類推を使用していたので、意味をつかみやすくなります。結局のところ、私はモナドが何であるかの3つの異なるビューになりました： 表示1：ラベルとしてのMonad 時々、モナドは特定のタイプのラベルとして考えます。たとえば、次のタイプの関数： myfunction :: IO Int myfunctionは、実行されるたびにInt値を生成する関数です。結果の型はIntではなくIO Intです。そのため、IOは、Int値がIOアクションが行われたプロセスの結果であることをユーザーに警告するInt値のラベルです。 その結果、このInt値はIOを持つプロセスからの値としてマークされているため、この値は「ダーティ」です。あなたのプロセスはもはや純粋ではありません。 見解2：モナドは、厄介なことが起こりうるプライベートな空間として。 すべてのプロセスが純粋で厳格なシステムでは、副作用が必要になる場合があります。そのため、モナドは、厄介な副作用を実行するための小さなスペースです。この空間では、あなたは純粋な世界から脱出し、不純なものに行き、あなたのプロセスを作り、価値を持って戻ってくることができます。 表示3：カテゴリー理論のようなモナド これは私が完全に理解していない見解です。モナドは、同じカテゴリーまたはサブカテゴリーの単なるファンクターです。たとえば、Int値があり、サブカテゴリとしてIO Intがあります。これは、IOプロセスの後に生成されるInt値です。 これらのビューは正しいですか？どちらがより正確ですか？

29 functional-programming  haskell  monad  side-effect 

このようなモナドの言語に依存しない説明を使用します。最初にモノイドを説明します。 モノイドは（おおよそ）のパラメータとして、いくつかの種類を取り、同じ型を返す関数のセットです。 モナドを取る関数の（おおよそ）が設定されているラッパーパラメータとしてタイプと同じラッパー・タイプを返します。 これらは説明であり、定義ではないことに注意してください。その説明を気軽に攻撃してください！ したがって、OO言語では、モナドは次のような操作構成を許可します。 Flier<Duck> m = new Flier<Duck>(duck).takeOff().flyAround().land() モナドは、含まれるクラスではなく、これらの操作のセマンティクスを定義および制御することに注意してください。 従来、OO言語では、クラス階層と継承を使用してこれらのセマンティクスを提供していました。したがってBird、メソッドtakeOff()、flyAround()およびを持つクラスがありland()、Duckはそれらを継承します。 しかし、その後、penguin.takeOff()失敗するため、飛べない鳥とのトラブルに巻き込まれます。例外のスローと処理に頼らなければなりません。 また、ペンギンがであると言うとBird、たとえばの階層もある場合、多重継承の問題に遭遇しますSwimmer。 基本的に、私たちはクラスをカテゴリーに分類し（カテゴリー理論に謝罪して）、個々のクラスではなくカテゴリーごとにセマンティクスを定義しようとしています。しかし、モナドは階層よりもそれを行うためのはるかに明確なメカニズムのようです。 したがって、この場合、Flier<T>上記の例のようなモナドができます。 Flier<Duck> m = new Flier<Duck>(duck).takeOff().flyAround().land() ...そして、インスタンス化することはありませんFlier<Penguin>。おそらくマーカーインターフェイスを使用して、静的な型付けを使用してそれを防ぐこともできます。または、実行時の機能チェックで解決します。しかし、実際には、プログラマーはゼロで割るべきではないという意味で、ペンギンをフライヤーに入れてはいけません。 また、より一般的に適用できます。チラシは鳥である必要はありません。たとえばFlier<Pterodactyl>、またはFlier<Squirrel>、これらの個々のタイプのセマンティクスを変更せずに。 型階層ではなく、コンテナ上の構成可能な関数によってセマンティクスを分類すると、特定の階層に適合する「やる、しない」クラスの古い問題を解決します。また、簡単＆はっきりと同じように、クラスの複数の意味を可能にするFlier<Duck>だけでなく、Swimmer<Duck>。動作をクラス階層で分類することにより、インピーダンスの不一致に苦労しているようです。モナドはそれをエレガントに処理します。 私の質問は、継承よりも合成を優先するようになったのと同じように、継承よりもモナドを優先することも理にかなっていますか？ （ところで、これがComp Sciにあるのか、それともComp Sciにあるのかはわかりませんでしたが、これは実際的なモデリングの問題のように見えます。

20 object-oriented  monad 

さらに別のFP +副作用の質問で申し訳ありませんが、私にこれに完全に答える既存の質問を見つけることができませんでした。 関数型プログラミングの私の（限られた）理解は、状態/副作用を最小限に抑え、ステートレスロジックから分離する必要があるということです。 また、これに対するHaskellのアプローチであるIOモナドを収集します。IOモナドは、プログラム自体のスコープ外であると見なされる、後で実行するために、ステートフルアクションをコンテナにラップすることによってこれを実現します。 私はこのパターンを理解しようとしていますが、実際にはPythonプロジェクトで使用するかどうかを決定するため、Haskell固有の仕様を避ける必要があります。 原油の着信。 私のプログラムがXMLファイルをJSONファイルに変換する場合： def main(): xml_data = read_file('input.xml') # impure json_data = convert(xml_data) # pure write_file('output.json', json_data) # impure これを行うためのIOモナドのアプローチは効果的ではありません： steps = list( read_file, convert, write_file, ) その後、実際にそれらのステップを呼び出すのではなく、インタープリターにそれを行わせることで、責任を放棄しますか？ または別の言い方をすれば、それは次のように書くことです： def main(): # pure def inner(): # impure xml_data = read_file('input.xml') json_data = convert(xml_data) write_file('output.json', json_data) return …

17 python  functional-programming  state  side-effect  monad 

最近、私はモナドがどのように機能するかについての知識を払拭しています。私はまたの概念を導入してきた「Comonad」として記述され、逆モナドのデュアル。しかし、頭を包むことはできません。 モナドを理解するために、私は自分自身に類推しました： モナドは、「表現のコンベアベルトを構築するための青写真」と見ることができます。 新しいMonad（新しい種類のコンベアベルトシステム）を定義するには、以下を定義する必要があります。 コンベアベルトに何かを置く方法。たとえば、コンベアベルトを「開始」します。（unitまたはとして知られているreturn） コンベアベルトの一部となるマシン（表現）をコンベアベルトに接続する方法。（joinまたはbindまたはとして知られてい>>=ます）。 （現在のコンベヤーベルトを取り出し、その内容物を捨て、として知られる新しいコンベヤーベルトを開始する3番目の操作がありますが、>>使用されることはほとんどありません。） 機械とコンベアが適切に連携するには、次のことを確認する必要があります。 コンベアベルトに何かを置いて機械に通した場合、出力は手動で機械に通したときと同じになります。（左身元） 既存のコンベヤーベルトの間にコンベヤーベルトを配置する場合、コンベヤーベルトが上にあるコンベヤーベルトではなく、単一の長いコンベヤーベルトで終わる必要があります。 （正しいアイデンティティ） マシンAを手動で使用し、コンベヤーに接続されたBCを介して結果を渡す場合、またはコンベヤーに接続されたABを使用し、Cを介して結果を手動で渡す場合、出力は重要ではありません。つまり、（（a >> = b）>> = c）は（a >> =（b >> = c））と同じである必要があります（結合性） 最も単純なコンベアベルトは、単に入力を受け取り、常に次の式に進むものです。これが「パイプライン」です。 別の可能性は、値に対して何らかの条件が満たされた場合にのみ次のマシンを通過させることです。つまり、中間の式の一部で値が許可されていないものに変更された場合、残りの式はスキップされます。これがHaskellで 'Maybe'モナドが行うことです。 また、値をマシンに渡す前または後に、値に対して他の派手な条件付きコピー/変更ルールを実行できます。例：パーサー（ここで、式が「失敗」の結果を返す場合、式の前の値が 出力として使用されます）。 もちろん、アナロジーは完全ではありませんが、モナドがどのように機能するかを大まかに表してくれることを願っています。 しかし、私はコモナドを理解するためにこの類推を頭に置くのに苦労しています。インターネット上で見つけたわずかな情報から、コモナドが定義していることを知っています。 extract、これはの逆ですreturn。つまり、Comonad から値を取得します。 duplicate、これはの逆のようなjoinものです。つまり、1つのComonadsから2つのComonadを作成します。 しかし、Comonadから抽出または複製しかできない場合、Comonadはどのようにインスタンス化できますか？そして、実際にどのように使用できますか？私はこの非常に素晴らしいプロジェクトとそれについての話を見ましたが（残念ながらほとんど理解していませんでした）、機能のどの部分がComonadによって正確に提供されるのかわかりません。 コモナとは何ですか？彼らは何のために役立ちますか？どのように使用できますか？彼らは食用ですか？

16 functional-programming  monad 

私はLINQがRx.NETに進化したC＃のバックグラウンドから来ましたが、FPには常に興味がありました。F＃でモナドといくつかのサイドプロジェクトを紹介した後、次のレベルに進む準備ができました。 さて、Scalaの人々からの無料のモナドに関するいくつかの講演と、HaskellまたはF＃での複数の記事の後、理解がIObservableチェーンに非常に類似していることを理解するための通訳付き文法が見つかりました。 FRPでは、チェーン内に留まる副作用や障害を含む、より小さなドメイン固有のチャンクから操作定義を作成し、一連の操作と副作用としてアプリケーションをモデル化します。無料のモナドでは、私が正しく理解していれば、ファンクターとして操作を行い、coyonedaを使用してそれらを持ち上げることで同じことを行います。 針をアプローチのいずれかに向けて傾ける両方の違いは何ですか？サービスまたはプログラムを定義するときの基本的な違いは何ですか？

14 functional-programming  monad  reactive 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 3年前に閉店しました。 私はモナドがどのように、何であるかを説明記事をたくさん読んだunitし、bindそれは目がいくつかのつまり完全に無視して、出血との奇妙なアナロジーに触れます（少なくとも私にとっては）それらのいくつかは、抽象ので圏論にまっすぐ急落仕事を、ブリトー、ボックスなど。 数週間の研究と多くの揚げたニューロンの後、（私は思う）モナドがどのように機能するかを理解しています。しかし、私の理解を逸するものがまだ1つあります。実際に触れている投稿はほとんどありません（IOと状態を除く）。 どうして？ モナドが重要なのはなぜですか？なぜそんなに重要なのですか？彼らが解決している問題は何ですか？これらの問題はMonadsでのみ解決できますか、それとも他の方法がありますか？

14 functional-programming  problem-solving  monad 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 Haskellのように、Scala OptionタイプがMaybeと呼ばれないのはなぜですか？ 多分私にはもっと「意味論的」になりますが、Optionには私が知らない別の動作があるかもしれません。 ScalaのOptionがMaybeと呼ばれなかった特別な理由はありますか？

13 language-design  haskell  scala  naming-standards  monad 

どのように私は、次のすべてを持っているシステムを構築します。 不変オブジェクトで純粋な関数を使用します。 関数が必要とする関数データのみに渡し、それ以上（つまり、大きなアプリケーション状態オブジェクトはなし） 関数への引数が多すぎることは避けてください。 関数に渡されるパラメーターが多すぎるのを避けるために、関数にパラメーターをパックおよびアンパックするためだけに新しいオブジェクトを作成する必要はありません。複数のアイテムを単一のオブジェクトとして関数にパックする場合、一時的に構築されたものではなく、そのオブジェクトをそのデータの所有者にしたい Stateモナドはルール2に違反しているように思えますが、モナドを介して織り込まれているため明らかではありません。 どういうわけかレンズを使用する必要があると感じていますが、非機能言語についてはほとんど書かれていません。 バックグラウンド 演習として、既存のアプリケーションの1つをオブジェクト指向スタイルから機能スタイルに変換しています。私が最初にやろうとしているのは、アプリケーションの内部コアをできるだけ多く作成することです。 私が聞いたことの1つは、純粋に機能的な言語で「状態」を管理する方法であり、これは私がステートモナドによって行われていると信じていることです。 「そのままの世界」を選択し、関数が戻ると、変化した世界の状態を返します。 たとえば、純粋に機能的な方法で「hello world」を実行する方法は、プログラムに画面の状態を渡し、「hello world」が印刷された画面の状態を受け取るようなものです。技術的には、純粋な関数を呼び出しているので、副作用はありません。 それに基づいて、アプリケーションを調べました。1。最初に、すべてのアプリケーション状態を単一のグローバルオブジェクト（GameState）に入れます。2。次に、GameStateを不変にしました。変更することはできません。変更が必要な場合は、新しいものを作成する必要があります。これを行うために、コピーコンストラクターを追加しました。オプションで、変更された1つ以上のフィールドを使用します。3.各アプリケーションに、GameStateをパラメーターとして渡します。関数内で、予定通りの処理を行った後、新しいGameStateを作成して返します。 純粋に機能的なコアと、そのGameStateをアプリケーションのメインワークフローループにフィードする外側のループの仕組み。 私の質問： さて、私の問題は、GameStateには約15種類の不変オブジェクトがあることです。最下位レベルの関数の多くは、スコアの保持など、これらのオブジェクトの一部のみで動作します。それで、スコアを計算する関数があるとしましょう。今日、GameStateはこの関数に渡され、新しいスコアで新しいGameStateを作成してスコアを変更します。 それについて何かが間違っているようです。この関数はGameState全体を必要としません。スコアオブジェクトが必要です。そこで、スコアを渡すように更新し、スコアのみを返します。 それは理にかなっているように思えたので、私は他の機能をさらに使いました。一部の関数では、GameStateから2、3、または4つのパラメーターを渡す必要がありますが、アプリケーションの外側のコア全体でパターンを使用しているため、ますます多くのアプリケーション状態を渡しています。たとえば、ワークフローループの先頭で、メソッドを呼び出し、メソッドを呼び出すメソッドなどを呼び出して、スコアが計算されるまで続けます。つまり、一番下の関数がスコアを計算するという理由だけで、現在のスコアがこれらすべてのレイヤーに渡されます。 だから今私は時々数十のパラメータを持つ関数を持っています。これらのパラメーターをオブジェクトに入れてパラメーターの数を減らすこともできますが、そのクラスは、単に渡すことを避けるために呼び出し時に単純に構築されるオブジェクトではなく、状態アプリケーション状態のマスターの場所にしたいです複数のパラメータで、それらを解凍します。 だから今、私が持っている問題は私の関数があまりにも深くネストされていることだろうかと思っています。これは小さな関数が必要なためです。そのため、関数が大きくなったらリファクタリングし、複数の小さな関数に分割します。しかし、そうすることでより深い階層が生成され、外部関数が直接それらのオブジェクトを操作していない場合でも、内部関数に渡されたものはすべて外部関数に渡される必要があります。 この問題を回避する方法に沿って単にGameStateを渡すように見えました。しかし、関数が必要とする以上の情報を関数に渡すという元の問題に戻りました。

12 c#  functional-programming  immutability  state  monad 

アプリケーションフレームワークで、パフォーマンスへの影響を無視できる場合（最大で1秒あたり10〜20イベント）、 モジュール間の通信の優先媒体として使用するのに、より保守的で柔軟なものは何ですか？イベントまたは先物/プロミス/モナド？ イベント（pub / sub、メディエーター）は疎結合を許可するため、より保守しやすいアプリであるとよく言われます...私の経験ではこれが否定されます。20以上のイベントがあると、デバッグが困難になり、リファクタリングも行われます-誰が、いつ、なぜ使用するのかを確認するのは非常に難しいためです。 約束（私はJavascriptでコーディングしています）は、イベントよりも醜くて気難しいものです。ただし、関数呼び出し間の接続を明確に確認できるため、アプリケーションロジックがより簡単になります。私が恐れていること。ただし、Promiseはそれらとのより強い結合をもたらすでしょう... PS：答えはJSに基づく必要はありません。他の関数型言語の経験は大歓迎です。

10 architecture  maintainability  async  event-programming  monad 

使いやすさ/保守性の観点からデザインが賢明なものは何なのか、コミュニティとの適合性に関しては何が優れているのかと思います。 データモデルを考える： type Name = String data Amount = Out | Some | Enough | Plenty deriving (Show, Eq) data Container = Container Name deriving (Show, Eq) data Category = Category Name deriving (Show, Eq) data Store = Store Name [Category] deriving (Show, Eq) data Item = Item Name Container …

9 functional-programming  haskell  validation  monad 

休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 6年前休業。 彼らがどんな問題を解決するのか分かりません。

9 haskell  pragmatism  monad 

エラーモナドでは、最初の失敗は実行を停止し、後続のバインドを介して障害を運ぶだけです。 どのモナドが成功を止めるのは、成功のみを先送りし、基本的には障害を飲み込み、前の失敗を無視して次のバインドを試みますか？ エラーモナドは、成功のようなこの失敗の処理に使用できますが、デフォルトのライブラリにこの特定の目的のためのモナドがあるかどうか、私の心のOrモナドのように、「これか、それか」に興味があります。 編集： 動作は次のようになります： Left "fail" >>= (\x -> Right "win") >>= (\x -> Left "ahh neener") >>= (\x -> Right (x + " yay")) エラーモナドでは、最初の左の値がそのまま繰り越されるため、その結果はになりLeft "fail"ます。私が望む動作は、上記が返すところですRight "win yay"私が自分で書くことができる実装するのは簡単なモナドですが、そのようなことをするために存在するものを考えました（Eitherを使用していないかもしれませんが、そのような動作について最初に頭に浮かぶのはそれです）。

9 haskell  monad