タグ付けされた質問 「functional-programming」

私はHaskellを学び、演習としてバイナリツリーを作成しています。通常の二分木を作成したので、それを自己均衡化に適応させたいと思います。そう： どちらが最も効率的ですか？ どちらが最も簡単に実装できますか？ 最もよく使用されるのはどれですか？ しかし、決定的に、どちらをお勧めしますか？ これは議論の余地があるため、ここに属していると思います。

18 haskell  functional-programming  data-structures  binary-tree 

F＃コードは多くの場合、型に対するパターンマッチのようです。もちろん match opt with | Some val -> Something(val) | None -> Different() よくあるようです。 しかし、OOPの観点から見ると、それはランタイムタイプチェックに基づく制御フローに非常によく似ており、通常は眉をひそめます。わかりやすく言うと、OOPではおそらくオーバーロードを使用することをお勧めします。 type T = abstract member Route : unit -> unit type Foo() = interface T with member this.Route() = printfn "Go left" type Bar() = interface T with member this.Route() = printfn "Go right" これは確かにより多くのコードです。OTOH、私のOOP-yの心には構造的な利点があるようです： …

18 object-oriented  functional-programming  f#  pattern-matching 

私はCSの学生です。現在、客観的な分析と設計を教えている講義に参加しています。ほとんどの場合、ユースケースの記述、クライアント用のアプリケーションを作成するときに直面する問題の分析、拡張可能で開発者にとって明確であり、クライアントがいくつかについて議論するときに問題が発生しないようにプロジェクトを設計する方法特徴。「客観的」なので、OOPの観点（クラスなど）から学習しています。 現在、ヘルパーツールとしてUMLを使用しています。私はOOPを十分に理解していると思いますが、機能的なパラダイムも学び、いくつかの小規模なプロジェクトでうまく使用しました。 私たちの先生は、「機能的なパラダイムについてはどうですか？」質問では、彼は関数型言語でより大きなプロジェクトをプログラミングしておらず、関数型プログラムがどのツールを使用しているのかを知りません。 それで、彼らは何を使うのでしょうか？このための方法論はありますか？それとも、そのようなことの必要はありませんか？

18 design  functional-programming  uml  modeling 

質問は次のとおりです。 ジェネレーターは関数型プログラミングのパラダイムを壊しますか？なぜですか？ はいの場合、ジェネレーターを関数型プログラミングで使用できますか？ 以下を考慮してください。 function * downCounter(maxValue) { yield maxValue; yield * downCounter(maxValue > 0 ? maxValue - 1 : 0); } let counter = downCounter(26); counter.next().value; // 26 counter.next().value; // 25 // ...etc downCounterこの方法は、ステートレス表示されます。同様に、downCounter同じ入力で呼び出すと、常に同じ出力になります。ただし、同時に、呼び出しnext()は一貫した結果を生成しません。 この例でcounterはジェネレーターオブジェクトであるため、ジェネレーターが関数型プログラミングパラダイムを破るかどうかはわかりません。そのため、呼び出しnext()はまったく同じで作成された別のジェネレーターオブジェクトと同じ結果を生成しますmaxValue。 同様someCollection[3]に、配列を呼び出すと、常に4番目の要素が返されます。同様next()に、ジェネレーターオブジェクトで4回呼び出すと、常に4番目の要素が返されます。 より多くのコンテキストについては、これらの質問は、プログラミングカタの作業中に提起されました。質問に答えた人は、関数型プログラミングでジェネレーターを使用できるかどうか、およびジェネレーターが状態を保持するかどうかという質問を提起しました。

17 javascript  functional-programming  iterator  ecmascript 

入力パラメーターの純度は実行時まで不明であるため、関数を入力パラメーターとして使用する場合、関数はすぐに不純であると見なされますか？ 関連：関数が関数の外部で定義されているが、パラメーターとして渡されない純粋な関数を適用する場合、副作用がなく、出力のみが入力のみに依存するという基準を満たしている場合でも純粋ですか？ コンテキストについては、JavaScriptで機能コードを作成しています。

17 functional-programming  pure-function 

さらに別の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 

関数型プログラミングの利点を説明する多くの記事で、C / C ++ / C＃/ Javaなどの命令型言語とは異なる「宣言型言語」と呼ばれるHaskell、ML、Scala、Clojureなどの関数型プログラミング言語を見てきました。私の質問は、関数型プログラミング言語を命令型ではなく宣言型にするものです。 宣言型プログラミングと命令型プログラミングの違いを説明するよくある説明は、命令型プログラミングでは、宣言型言語の「何をすべきか」ではなく「何をするか」をコンピューターに伝えるというものです。この説明に関して私が抱えている問題は、すべてのプログラミング言語で常に両方を実行しているということです。最下位レベルのアセンブリに移動しても、コンピューターに「何をすべきか」と伝え、CPUに2つの数字を追加するように指示します。追加の実行方法については指示しません。Haskellのような高レベルの純粋な関数型言語であるスペクトルのもう一方の端に行くと、実際には特定のタスクを達成する方法をコンピューターに伝えていることになります。それはあなたのプログラムがコンピューターが単独で達成する方法を知らない特定のタスクを達成するための一連の命令です。Haskell、Clojureなどの言語はC / C ++ / C＃/ Javaより明らかに高いレベルであり、遅延評価、不変データ構造、匿名関数、カリー化、永続データ構造などの機能を提供することを理解しています関数型プログラミングは可能かつ効率的ですが、宣言型言語として分類しません。 私にとって純粋な宣言型言語は、宣言のみで構成される言語であり、そのような言語の例はCSSです（はい、CSSは技術的にはプログラミング言語ではないことを知っています）。CSSには、ページのHTMLおよびJavascriptで使用されるスタイル宣言が含まれています。CSSは宣言以外に何もできません。クラス関数、つまり、パラメーターに基づいて表示するスタイルを決定する関数、CSSスクリプトを実行できない関数などは作成できません。プログラミング言語）。 更新： 私は最近Prologをいじくり回してきましたが、完全に宣言的なプログラミング言語だけではない場合、Prologは完全に宣言的な言語（少なくとも私の意見では）に最も近いプログラミング言語です。Prologでプログラミングを精緻化するには、ファクト（特定の入力に対してtrueを返す述語関数）またはルール（入力に基づいて特定の条件/パターンに対してtrueを返す述語関数）のいずれかを宣言することによって行われます。パターンマッチング手法を使用して定義されます。プロローグで何かを行うには、述語の1つ以上の入力を変数に置き換えてナレッジベースを照会し、プロローグが述語が成功する変数の値を見つけようとします。 私のポイントは、プロローグには命令的な指示はなく、基本的にはコンピューターに知っていることを伝え（宣言）、知識について尋ねる（問い合わせる）ことです。関数型プログラミング言語では、メモリの場所を直接操作したり、段階的に計算を書き込んだりしていなくても、値の取得、関数Xの呼び出し、それに1の追加などの指示を与えています。私は間違っているかもしれませんが、Haskell、ML、Scala、Clojureでのプログラミングがこの意味で宣言的であるとは言いません。上で説明した意味で、適切で、真で、純粋な関数型プログラミング宣言です。

17 functional-programming  prolog  imperative-programming  declarative-programming 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 過去1年間、私はScalaコードを書いてきました（Javaのバックグラウンドから来ています）。vals、caseクラス、map / filter / lambda関数、暗黙的および型推論を使用して、よりシンプルでクリーンなコードを作成できる方法が本当に気に入りました。主にAkkaベースのアプリケーションに使用しました。 今年は、関数型プログラミングが大好きな新しいチームとScalaプロジェクトに参加しています。それらはScalazを頻繁に使用し、コードはあらゆる場所にapplicatives、context bounds、reader / writer / stateモナドで満たされ、メインメソッドもI / Oモナドに「ラップ」されます。彼らの推論は、これによりコンパイラがコードが正しいことを主張する際に「私たちのために働く」ようにし、各関数に副作用がないことです。 それでも、私の観点からすると、この構文はすべてビジネスロジックの邪魔になります。たとえば、「MyBusinessObject」のタイプは問題ありません。「List [MyBusinessObject]」、「Option [MyBusinessObject]」、「Future [MyBusinessObject]」などのタイプも同様です。それらはすべて明確な意味と目的を持っています。一方、次のようなコード： def method[M[_]: Applicative] = { case (a, b) => (ca[M](a) |@| cb[M](b)) { case t @ (ra, rb) => if (ra.result && rb.result) t.right else t.left } } それはプログラムに複雑さを追加しますか、それとも私がこのプログラミング方法に慣れていないのは私だけですか？

17 functional-programming  scala 

純粋に関数型またはほぼ純粋に関数型の言語は、不変であり、関数型プログラミングのステートレススタイルによく適合するため、永続的なデータ構造の恩恵を受けます。 ただし、Javaのような（状態ベース、OOP）言語の永続データ構造のライブラリが時々見られます。永続的なデータ構造を支持してよく聞かれる主張は、不変であるためスレッドセーフであるということです。 ただし、永続データ構造がスレッドセーフである理由は、1つのスレッドが永続コレクションに要素を「追加」すると、操作は元の要素に要素が追加された新しいコレクションを返すためです。したがって、他のスレッドは元のコレクションを参照します。もちろん、2つのコレクションは多くの内部状態を共有しています。そのため、これらの永続的な構造は効率的です。 しかし、スレッドごとにデータの状態が異なるため、永続データ構造だけでは、あるスレッドが他のスレッドに見える変更を行うシナリオを処理するのに十分ではないように思われます。このためには、アトム、リファレンス、ソフトウェアトランザクションメモリ、またはクラシックロックや同期メカニズムなどのデバイスを使用する必要があるようです。 それでは、なぜPDSの不変性が「スレッドセーフ」にとって有益であると宣伝されているのでしょうか。PDSが同期、または並行性の問題の解決に役立つ実際の例はありますか？または、PDSは、関数型プログラミングスタイルをサポートするオブジェクトへのステートレスインターフェイスを提供する単なる方法ですか？

17 functional-programming  data-structures  multithreading  concurrency 

現在のところ、この質問はQ＆A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、おそらく再開できると思われる場合は、ヘルプセンターをご覧ください。 8年前に閉鎖されました。 関数型プログラミングをアクセシブルな方法で説明する本を探しています。また、私はあまり退屈ではなく、難解な言語を使用しないものを好むでしょう。 理想的には、関数型プログラミングが命令型アプローチよりもエレガントでシンプルなソリューションにつながる状況を示す例を使用します。 プログラミングの経験はある程度ありますが、関数型プログラミングの知識はありません。提案をありがとう

17 books  functional-programming 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 Haskellのような言語のWebフレームワークを検索中に、Ur / Webプロジェクトに出会いました。一人が行った非常に興味深いプロジェクトのようです。 基本的に、これはWebプログラミング用のドメイン固有の純粋に機能的な言語であり、MLとHaskellを最大限に活用しています。構文はMLですが、Haskellの型クラスとモナドがあり、厳密に評価されています。サーバー側はネイティブコードにコンパイルされ、クライアントはJavascriptにコンパイルされます。他のアドバタイズされた利点については、スライドとFAQページを参照してください。 見てデモやそのソースコードは、私はこのプロジェクトは非常に有望であると思います。最新バージョンは20110123であるため、現時点では活発に開発中のようです。 ここで誰かがそれをさらに経験したことがありますか？MLのやや冗長な構文とは別に、Haskellと比較して問題/迷惑はありますか？

17 web-development  functional-programming  haskell  web-framework 

最近、私はモナドがどのように機能するかについての知識を払拭しています。私はまたの概念を導入してきた「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 

このアイデアは、+、-、％などのファクト演算子に触発されており、1つまたは2つの引数が渡され、副作用がない関数と見なすことができます。私または他の誰かが、3つ以上の引数の受け渡しを停止し、戻り値を介してのみ機能する言語を作成すると仮定します。 a）そのような言語はコードを理解しやすくするでしょうか？ b）コードの流れはより明確になりますか？（より多くのステップを強制し、潜在的に少ない対話を「非表示」にします c）制限により、より複雑なプログラムでは言語が非常に大きくなりますか？ d）（ボーナス）賛否両論に関するその他のコメント 注意： 2つの決定を行う必要があります。1つ目は、main（）または同等の外部でのユーザー入力を許可するかどうか、および配列/構造体を渡すときに何が起こるかについてのルールです。たとえば、1つの関数で複数の値を追加したい場合、その関数を配列にまとめることで制限を回避できます。これは、配列または構造体がそれ自体と対話することを許可しないことで停止できます。これにより、たとえば、各数値をその位置に応じて異なる量で除算できます。

16 design  programming-languages  functional-programming  functions 

私は誰もがフォームの一般的なメソッドに精通していると確信しています： T DoSomething<T>(T item) この関数は、パラメータポリモーフィック（PP）、特にランク1 PP とも呼ばれます。 このメソッドは、次の形式の関数オブジェクトを使用して表現できるとしましょう。 <T> : T -> T つまり、<T>1つの型パラメーターを受け取り、1つの型のパラメーターをT -> T受け取りT、同じ型の値を返すことを意味します。 その場合、次はランク2 PP関数になります。 (<T> : T -> T) -> int この関数は、型パラメーター自体を受け取りませんが、型パラメーターを受け取る関数を受け取ります。これを繰り返し続けて、ネストをより深くし、より高いランクのPPを取得できます。 この機能は、プログラミング言語では非常にまれです。Haskellでさえ、デフォルトでは許可していません。 便利ですか？他の方法では説明が難しい動作を説明できますか？ また、何かが命令的であるとはどういう意味ですか？（このコンテキストで）

16 programming-languages  functional-programming  type-systems  generics 

いくつかのことで言われて、あなたはそれらの極端にSOLID原則を取る場合、あなたは関数型プログラミングで終わります。この記事に同意しますが、インターフェイス/オブジェクトから関数/クロージャへの移行でいくつかのセマンティクスが失われると思うので、関数型プログラミングがどのように損失を軽減できるかを知りたいと思います。 記事から： さらに、インターフェイス分離の原則（ISP）を厳密に適用すると、ヘッダーインターフェイスよりもロールインターフェイスを優先する必要があることを理解できます。 デザインをどんどん小さなインターフェースに向けていくと、最終的には究極のロールインターフェース、つまり単一のメソッドを持つインターフェースに到達します。これは私によく起こります。以下に例を示します。 public interface IMessageQuery { string Read(int id); } に依存する場合IMessageQuery、暗黙の契約の一部は、呼び出しRead(id)が特定のIDのメッセージを検索して返すことです。 これを、同等の機能シグネチャである依存関係と比較してください int -> string。追加の手がかりがなければ、この関数は単純なものになりToString()ます。を実装IMessageQuery.Read(int id)したToString()場合、意図的に破壊されたと非難する可能性があります！ それでは、機能的なプログラマは、名前の良いインターフェイスのセマンティクスを保持するために何ができるでしょうか？たとえば、単一のメンバーでレコードタイプを作成することは一般的ですか？ type MessageQuery = { Read: int -> string }

16 object-oriented  functional-programming  solid