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

最近、私はハスケルに深く興味を持っています。 新しい概念（forallキーワードやSTモナドなど）とHaskellの型システム全般を学習しようとしている間、私は絶えずカテゴリー理論とラムダ計算の概念に出くわしました。だから、私は思う： Haskellの型システムを十分に理解するには、数学の他のどの分野が重要ですか？ これらの数学の厳密な研究を見逃して、代わりに特定の関連する概念に焦点を当てることはできますか？（例えば、ラムダ計算における数量詞。）もしそうなら、どの概念が不可欠ですか？ タイプとプログラミング言語をすぐに取り上げたいと思っていますが、適切と思われる代替の参考資料を提案してください。

9 programming-languages  functional-programming  math  haskell  type-systems 

パイプとフィルターのアーキテクチャパターンは、各要素の出力が次の要素の入力になるように配置された一連の処理要素として定義されます。すべての例は、ある種の共有バッファを介して実行されるプロセス間またはスレッド間接続を考慮しているようです。 私には、Haskell関数構成が同じタスクを実行しているようです。関数の順序付けだけで、明示的なバッファーがパイプとして使用されていない場合でも、それはこのパターンのインスタンスであると言えますか？はいの場合、怠惰でない言語でも同じことが言えますか？

9 design  functional-programming  haskell  architectural-patterns 

以前の質問で、関数型プログラミング言語は物理エンジンなどの動的システムには適していないと言われています。これは、主にオブジェクトの変更にコストがかかるためです。このステートメントはどの程度現実的ですか、そしてその理由は何ですか

9 functional-programming  haskell  clojure  immutability 

私はRebolに遭遇し、それについて疑問に思いました。 ここから次のスクリプトに遭遇しました： use [feed questions answers][ feed: load-xml/dom http://stackoverflow.com/feeds/tag/rebol questions: map-each entry feed/get-by-tag <entry> [ find/match entry/get <id> "http://stackoverflow.com/q/" ] answers: make block! length? questions foreach question questions [ question: load-xml/dom join http://stackoverflow.com/feeds/question/ question foreach entry next question/get-by-tag <entry> [append answers entry/tree] ] insert clear feed/find-element <entry> answers feed/flatten ] …

9 functional-programming  rebol 

Haskell、O'Caml、またはLISPが登場するずっと以前から、高次関数は学術研究の主題であり、数学ではSchönfinkel（1967年）とHaskell Curry（1968年）はすでにカレーなどの手法を適用していましたが、どのプログラミング言語でも利用できるようになる前でした。 Wikipediaによると、Scheme はファーストクラスの市民として適切な高階関数を導入した最初の言語でしたが、元のアイデアを私たちに帰すことができる人はいますか？たぶん、1930年代にラムダ計算を発明したアロンゾ教会ですか？より具体的には、私がいくつかの本やオンラインリソースでさまざまな言い換えで見た次の定義を誰が作り出したのですか？ 関数が別の関数を引数として取る場合、または関数を返す場合、その関数は高次であると見なされます。関数を引数または戻り値の型として使用しない関数は、一次関数と呼ばれます。

9 functional-programming  history  haskell  scheme  higher-order-functions 

使いやすさ/保守性の観点からデザインが賢明なものは何なのか、コミュニティとの適合性に関しては何が優れているのかと思います。 データモデルを考える： 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 

私は関数型プログラミングに関する記事を毎日読んでおり、可能な限りいくつかのプラクティスを適用しようとしています。しかし、私はカレーや部分的なアプリケーションで何がユニークなのか理解していません。 例として、このGroovyコードを見てみましょう。 def mul = { a, b -> a * b } def tripler1 = mul.curry(3) def tripler2 = { mul(3, it) } 私は違いが何であるかを理解していないtripler1とtripler2。どちらも同じではないですか？「カレー化」は、Groovy、Scala、Haskellなどの純粋または部分的な関数型言語でサポートされています。ただし、別の名前付きまたは匿名を作成するだけで、同じこと（左カレー、右カレー、nカレー、または部分アプリケーション）を実行できます。tripler2ほとんどの言語（Cでも）でパラメーターを元の関数（など）に転送する関数またはクロージャー ここで何か不足していますか？Grailsアプリケーションでカレーや部分的なアプリケーションを使用できる場所はありますが、「どうして違うの？」 教えてください。 編集：皆さんは、デフォルトのパラメーターを元の関数に転送する別の関数を作成/呼び出すよりも、部分的なアプリケーション/カリー化が単に効率的であると言っていますか？

9 functional-programming  groovy  higher-order-functions  currying 

手続き型およびOOPから来た関数型プログラミングに切り替える場合、「この新しい考え方」について事前に知っておくべきことは何ですか。 FPの世界でのダイビングに向けてどのように準備し、それを初めて体験するのですか？ 最初に学び、最初に設定するための基本は何ですか？

9 functional-programming 

私が読んだ最悪のアンチパターンを読んでいるときに、この投稿のリンクをクリックして、アンチパターンに関するWebサイトにアクセスしました。 そして、http：//sourcemaking.com/antipatterns/functional-decompositionのページは私に不思議に思いました。 このアンチパターンはどれほどひどいですか、それともアンチパターンですか？今日私はほとんどOOPプログラミングを行っていますが、Javaのような純粋なOOPのすべての言語や、それらがもたらす設計慣行にもまだ気が進まないためです。コードを書いている間も、関数型プログラミングにはいくつかの特徴があります。 そして、これは質問を持ち出しました、私はOOP + Functionalスタイルに固執することによって間違っていますか、それとも業界では一般的であり、実際にはそれほど悪いことではありませんか？ 私が経験から知っていることは、OOP + Functionalスタイルは純粋なOOP開発者と完全には互換性がないということです。しかし、同時に、OOP開発者はOOP +機能開発に問題を抱えていますが、反対意見は、OOPソリューションは非常に頻繁に設計されすぎて使用が困難であり、私の経験から、少しも簡単ではなく、実際には非常に深刻なバグを隠すためにいくつかの盲点を導入しました。 したがって、これらのトピックについて同僚と話し合ったとしても、どの方法も実際には完璧ではないという結論に達しました。そして、私はまだ質問に答えられていません。 OOP問題は、同じスレッド内の別の投稿からのリンクによっても強化されました。リンクは、JavaスタイルのOOP http://chaosinmotion.com/blog/?p=622にあります。 では、関数型プログラミングとOOPを混合することに対する一般的な態度はどのようなものでしょうか。そして、開発者が達成するために努力すべきバランスは何ですか？

9 object-oriented  functional-programming  anti-patterns 

関数型プログラミングの原則の1つは、純粋関数の使用です。ピュア関数は、副作用がなく、参照的に透過的な関数です。 ゲッターは参照透過的ではありません-ゲッターへの呼び出しの間にセッターが呼び出されると、ゲッターの戻り値はパラメーターがない（通常はパラメーターがない）場合でも変化します。 セッターは副作用を生み出します-セッターを呼び出すと、通常、戻り値ではない値が操作されます（実際、伝統的にセッターは何も返しません）。 Scalaでは、2つのパラダイム（関数型とオブジェクト指向）を組み合わせてJavaのような言語で行うようにゲッター/セッターを使用しているという事実を受け入れてくれることを知っています。 Haskellのような言語（私は流暢ではありませんが、「純粋な」関数型言語に当てはまると言われています）では、ゲッターが参照透過でセッターであるようにオブジェクトのプロパティをモデル化する方法に興味があります副作用はありませんか？ 解決策は、セッターが呼び出されたオブジェクトのコピーをセッターの戻り値として返すことであり、このコピーにはプロパティ値の変更が含まれていますか？

9 functional-programming  haskell  scala 

チェスゲームエンジンを作成する場合、どのプログラミングパラダイム（OOP、手続き型など）を使用し、なぜそれを選択するのでしょうか。チェスエンジンとは、現在のボードを評価し、コンピューターの次の動きを決定するプログラムの部分を意味します。 チェスエンジンを書くのは楽しいかもしれないと思ったので、質問します。それから、関数型プログラミングを学ぶためのプロジェクトとしてそれを使うことができると思いました。次に、いくつかの問題が機能的パラダイムにあまり適していないことに気付きました。それから、これは良い議論の餌になるかもしれないと私は思いました。

9 object-oriented  functional-programming  paradigms  chess 

このシリーズを進めています。作者は、オブジェクト指向プログラミングでは状態が維持されるため、単体テストを書くのは難しいと述べています。彼はまた、関数型プログラミングは（常にではない）状態を維持しないので、単体テストを書く方が簡単だとも言っています。この問題を示す例は見当たりませんでした。これに該当する場合、オブジェクト指向プログラミングと関数型プログラミングの単体テストを比較する例を教えていただけますか？

9 object-oriented  unit-testing  functional-programming 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 3年前休業。 彼らの言語には、状態を変化させる関数の名前が感嘆符で終わらなければならない慣習があると誰かが言うのを聞いた 私はもっ​​と機能的なコードを書こうとしているのですが、副作用ステータスに従って関数を何とかマークするアイデアが好きです。つまり、なし、内向きの副作用、外向きの副作用（私は正しいfp用語を知らないですが、望む）。 自分の命名スキームを思いつくのは簡単ですが、そのようなスキームや慣習がホームベイクする前にすでに存在しているかどうか疑問に思っていました。 編集：すべての回答に感謝します。それはまさに私が求めていたものであり、それらはすべて本当に有用であることがわかりました。おそらく、古いJavaScriptをリファクタリングしているので、静的に型付けされた言語では、副作用のあるコードとないコードの違いを強制できるかもしれないが、自分で付けた命名規則に頼らなければならないでしょう。 edit2：これを主にオピニオンベースとして閉じるmodについては、私は同意しなければなりません。私は、もしあれば、どのような慣習が一般的に使用されているのかを尋ねていました-これは誰かの定義によると、意見ではなく事実の問題です！

9 coding-style  functional-programming  coding-standards  naming  conventions 

Haskellでは、タイプa -> Maybe bを使用して、タイプの値を返すかb、何も返さない（失敗する）関数をモデル化できます。 私がタイプしている場合a1, ..., a(n+1)や機能f1, ..., fnを持つ、fi :: ai -> Maybe a(i+1)すべてのためにi、1 <= i <= n私は使用して機能をチェーンできる>>=のオペレータMaybeモナドと書き込みを： f1 x >>= f2 >>= f3 >>=... >>= fn >>=各関数があれば、その前身は、意味のある値を返したように適用されていることをオペレータを確実にします。チェーン内の関数が失敗するとすぐに、チェーン全体が失敗し（戻り値Nothing）、チェーン内の以降の関数は評価されません。 同じ入力で複数の関数を試し、1つの関数が成功したらすぐに戻りたいという似たようなパターンがあります。すべての関数が失敗すると（return Nothing）、計算全体が失敗します。より正確には、私には関数がf1, ..., fn :: a -> Maybe bあり、関数を定義します tryFunctions :: [a -> Maybe b] -> a -> Maybe b tryFunctions [] …

9 functional-programming  haskell  patterns-and-practices 

実行時間の長いswitchケースまたはif-else-if構文は、適用可能な場合はどこでも、ポリモーフィズムを使用してOOPで回避されます。 値を突き合わせて分岐する代わりに、分岐はクラスレベル自体で行われます。 関数型プログラミングのパラダイム、特にClojureで同様のアプローチをどのように適用できますか？

9 functional-programming  clojure