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

関数型プログラミングは、抽象化を構築し、コンピュータプログラムを構成する計算を表現するための手段として主に関数を使用するプログラミングパラダイムです。

6
カテゴリー理論は関数型プログラミングの学習に役立ちますか？
私はHaskellを学んでおり、その言語に魅了されています。しかし、私には深刻な数学やCSのバックグラウンドはありません。しかし、私は経験豊富なソフトウェアプログラマです。 Haskellでより良くなるために、カテゴリー理論を学びたいです。 Haskellを理解するための良い基礎を提供するために、カテゴリー理論のどのトピックを学ぶべきですか？
3
依存型と改良型
誰かが依存型と絞り込み型の違いを説明できますか？私が理解しているように、絞り込み型には、述語を満たす型のすべての値が含まれます。それらを区別する依存型の機能はありますか？ それが役立つ場合、Liquid Haskellプロジェクトを介して洗練された型、CoqおよびAgdaを介して依存型に出会いました。とはいえ、私は理論がどのように異なるかについての説明を探しています。
3
関数型言語のアルゴリズムの複雑さはどのようにモデル化されますか？
アルゴリズムの複雑さは、下位レベルの詳細に依存しないように設計されていますが、命令型モデルに基づいています。たとえば、ツリー内のノードへの配列アクセスや変更にはO（1）時間かかります。これは、純粋な関数型言語では当てはまりません。Haskellリストへのアクセスには直線的な時間がかかります。ツリー内のノードを変更するには、ツリーの新しいコピーを作成する必要があります。 次に、関数型言語のアルゴリズムの複雑さの代替モデリングが必要ですか？
3
ピュア/依存型システムの簡単だが完全な説明は何ですか？
何かが単純な場合は、いくつかの言葉で完全に説明できるはずです。これは、λ計算に対して行うことができます。 λ計算は、構文規則（基本的に構造）であり、リダクションルール（特定のパターンが出現するまで、そのようなパターンが存在しなくなるまで繰り返し検索/置換手順が適用されることを意味します）。 文法： Term = (Term Term) | (λ Var . Term) | Var 削減ルール： ((λ var body) term) -> SUBS(body,var,term) where `SUBS` replaces all occurrences of `var` by `term` in `body`, avoiding name capture. 例： (λ a . a) -> (λ a a) ((λ a . (λ b . …
2
機能的リアクティブプログラミングとアクターモデルはどのように相互に関連していますか？
FRPは、純粋な機能によるイベントと動作のストリーミングに関するものです。少なくともAkkaで実装されているアクターモデルは、アクターと呼ばれる不純なオブジェクトを介した不変メッセージ（離散イベントと見なすことができます）のストリーミングに関するものです。 したがって、表面上はそれらは関連しているように見えます。 それらがどのように関連しているかについて、他に何を言えますか？また、それらのどれが異なるアプリケーションドメインにより適切であるかもしれないかについて何が言えるでしょうか？
2
ラムダ計算は純粋に構文ですか？
私はラムダ計算について数週間読んでいますが、既存の数学関数と実質的に異なるものはまだ見ていません。それは単なる表記の問題なのか、新しいものがあるのか​​を知りたいですすべての数学関数に適用されるわけではない、ラムダ計算の公理によって作成されたプロパティまたはルール。だから、例えば、私はそれを読んだ： 「匿名関数が存在する可能性があります」：Lambda関数は匿名ではなく、すべてラムダと呼ばれます。名前が重要でない場合、異なる関数に同じ変数を使用することは数学表記で許容されます。たとえば、ガロア接続の2つの関数は両方とも*と呼ばれることがよくあります。 「関数は関数を入力として受け入れることができます」：これは新しくなく、通常の関数でこれを行うことができます。 「関数はブラックボックスです」：入力と出力だけが数学関数の有効な説明でもあります... これは議論や意見の質問のように思えるかもしれませんが、この質問には「正しい」答えがあるはずです。ラムダ計算が単なる数学関数であるか、またはラムダと通常の関数の間に実質的または意味的な違いがあるかどうかを知るために、表記法、構文規則のいずれかを知りたいです。
2
純粋に機能的な言語でプロローグインタープリターを実装する方法
純粋に関数型の言語でPrologインタープリターを実装する方法について、擬似コードに関する明確なリファレンスがありますか？私がこれまでに発見したのは、命令型言語のみを扱っているようで、Prolog自体の実装にすぎないか、解釈に使用する具体的なアルゴリズムを提供していません。私は答えにとても感謝しています。
3
SMLのファンクターとカテゴリー理論の関係は何ですか？
この答えでのアンドレイ・バウアーのこの声明と同じ考え方に沿って Haskellコミュニティは、カテゴリ理論に触発されたいくつかの手法を開発しました。モナドは最もよく知られていますが、モナドと混同しないでください。 SMLのファンクターとカテゴリー理論のファンクターの関係は何ですか？ HaskellやOCamlなどの他の言語のファンクターの詳細については知らないので、価値のある情報がある場合は、他の言語のセクションも追加してください。
2
計算式はモナドと同じですか？
この質問は、Computer Science Stack Exchangeで回答できるため、Stack Overflowから移行されました。 5年前に移行され ました。 私はまだ関数型プログラミング（f＃を使用）を学んでおり、最近計算式について読み始めました。私はまだ概念を完全には理解していません。モナドに関するすべての記事を読んでいるときに確信が持てない1つのこと（それらのほとんどはHaskellに基づいて書かれています）は計算式とモナドの関係です。 すべてを書いたので、ここに私の質問です（実際には2つの質問）。 すべてのF＃計算式はモナドですか？すべてのモナドをF＃計算式で表現できますか？ この Tomas Petricekの投稿を読んだことがあり、よく理解できれば、計算式はモナド以上のものであると述べていますが、これを正しく解釈できるかどうかはわかりません。
2
カテゴリー理論が意味することは、高階関数をどのように扱うかをまだ知りませんか？
読んでウダイ・レディの 答えをするSMLでファンクタとカテゴリの理論との関係とは？Uday州 カテゴリー理論は、高階関数の扱い方をまだ知らない。いつか、そうなるでしょう。 カテゴリー理論は数学の基礎として役立つと思ったので、数学と高階関数のすべてを導き出すことができるはずです。 それでは、カテゴリ理論が意味することは、高階関数の扱い方をまだ知らないということですか？カテゴリー理論を数学の基礎として考えることは有効ですか？
4
関数型プログラミングで永続データ構造を使用するのはなぜですか？
関数型プログラミングでは、永続的なデータ構造と不変オブジェクトが使用されます。私の質問は、なぜこのようなデータ構造をここに持つことが重要なのですか？データ構造が永続的でない場合、どうなるかを低レベルで理解したいですか？プログラムはより頻繁にクラッシュしますか？
2
プログラミングのカテゴリー理論（ではない）？
Haskellやそれほど純粋ではないFP言語を学んだ後、カテゴリ理論について読むことにしました。カテゴリー理論をよく理解した後、私はカテゴリー理論の概念を使用してプログラムの設計を考える方法について考え始めましたが、どんなに一生懸命試みても、これは進むべき道ではないようです。 カテゴリー理論をプログラムの設計に関連付けるための多くの失敗した試みを費やした後、私は次のような結論に達しました： カテゴリ理論は、プログラミング言語を設計するときに役立ちます。 カテゴリ理論は、プログラムを設計するときに使用するものではありません（カテゴリの原則に基づいて設計された言語を使用する場合でも）。例：Haskellでプログラミングする場合、カテゴリ理論の概念ではなく、型、型コンストラクタ、関数、高階関数などを使用してプログラムを設計します。 要約すると、下層システムがあります（順序は低から高です）： カテゴリ理論->プログラミング言語->プログラム 特定のレイヤーでは、直下のレイヤーの概念を使用します。 この理解は正しいですか？そうでない場合は、プログラムの設計でカテゴリ理論の概念を直接使用できると考えている場合は、いくつかの記事またはブログの投稿を参照してください。 注：プログラムを設計するということは、並行性、並列処理、リアクティブ、メッセージパッシングなどのさまざまな概念に基づいてプログラムを設計することを意味します。
5
関数型プログラミング以外のラムダ計算？
この質問は、コンピューターサイエンススタック交換で回答できるため、理論的なコンピューターサイエンススタック交換から移行されました。 7年前に移行され ました。 私は大学生です。現在、ラムダ計算を勉強しています。ただし、これがなぜ私にとって役立つのかを正確に理解するのはまだ困難です。関数型プログラミングをたくさん行うと便利かもしれませんが、関数型プログラミングを学ぶのにそれは本当に必要ではないと思います、どう思いますか？ 第二に、コンピューターサイエンスの領域内ではあるが関数型プログラミング言語以外でのLambda Calculusの使用はありますか？
1
なぜ関数型プログラミングは動的ツリーを研究していないのですか？
動的ツリーは、ネットワークフロー、動的グラフ、組み合わせの問題（TarjanおよびWerneckによる「Dynamic Trees in Practice」）や最近の辞書のマージ（Adam Karczmarzによる「A Simple Mergeable Dictionary」）などの問題の解決に重要な役割を果たします。 動的ツリーについては、1983年のSleator＆Tarjanの論文「動的ツリーのデータ構造」に記載されている定義を参照します。 Edward Kmettは、主にC ++の対応物の翻訳として、STツリーのバージョンを実装しました。リンクカットツリーを参照してください。 クリス・オカサキは、著名な著書「純粋に機能的なデータ構造」に、スプレイツリーの限定的な実装を書いています。 Ralf HinzeとRoss Patersonは、2〜3本のフィンガーツリーと呼ばれる機能的なデータ構造を導入しましたが、動的ツリーの元の定義とは多少異なる目的があります。 動的ツリーの実装（およびパフォーマンス）は、次の3つのアプローチに従って分割されます。 ETツリー（オイラーツアー）が重要な役割を果たす線形化。純粋に機能的な研究は見つかりませんでした。 STツリーが主力であるパス分解では、Kmettのバージョンが見つかりました。 ツリーの収縮。トップツリー、トポロジツリー、およびRCツリーがプレーヤーです。純粋に機能的な研究は見つかりませんでした。 純粋に機能的な分析と実装は、Splay、AVL、赤黒木で見つけることができますが、それらは動的な木ではありません。前者は後者のシャドウ（仮想または補助とも呼ばれる）データ構造と見なされます。 だから、私の質問は： 関数型プログラミング研究コミュニティが動的ツリーデータ構造に参加しない理由（欠点、弱点）は何ですか？
1
どのクラスのデータ構造を永続化できますか？
永続データ構造は不変のデータ構造です。それらに対する操作は、データ構造の新しい「コピー」を返しますが、操作によって変更されます。ただし、古いデータ構造は変更されません。一般に、効率性は、基礎となるデータの一部を共有し、データ構造の完全なコピーを回避することにより達成されます。 質問： （同じまたは非常に類似した複雑さを維持しながら）永続化できるデータ構造のクラスに関する結果はありますか？ （同じまたは非常に類似した複雑さを維持しながら）すべてのデータ構造を永続化できますか？ （同じまたは非常に類似した複雑さを維持しながら）永続化できないデータ構造はありますか？
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.