タグ

functionalに関するunaristのブックマーク (49)

  • 「参照透過である」とは、何から何への参照がどういう条件を満たすことを言うのか - Qiita

    関数型プログラミングが流行していることもあって、頻繁に耳にする「参照透過性」という用語について考えます。 ∥ 参照透過性 - Wikipedia その過程で目にした、Stack Overflow 上の Reddy 氏の発言が面白かったので、ザックリと訳します。 用語の起源と、それがプログラミング言語に導入された経緯 一応意味は分かってはいるんですが、なぜ「副作用のない関数呼び出し」やら「変数への再代入の禁止」といった特性を「参照透過性」と呼称するのかが分かりませんでした。この場合の「参照」は、何が何を参照することであり、また、それがどういう状態にあることを「透過である」としているのかが、通り一遍調べてみても分かりませんでしたので、掘りに行ってきます。 英語Wikipedia の方には、この考え方がプログラミングの概念として導入された経緯についての論文が参考文献として挙げられています。

    「参照透過である」とは、何から何への参照がどういう条件を満たすことを言うのか - Qiita
  • 内包表記について、すごい合同勉強会で話した | そんなこと覚えてない

    すごい合同勉強会2014 in 広島でセッションしたので内容を公開しておく。 今回は「私がモナドの内包表記という名前を知った時の感覚を伝えよう」というのが目的でした。 さりげなく「私がモナドに感じている効能を伝える」というのもしているのですが、そこは当にさりげなく。 内包表記。その意味を知らずに5年前ぐらいにpythonで利用していて、forやif文字通りにうけとっており、その動作を正しく理解できてないときがありました。 現在とその間にHaskellを学び、その5年前の自分に内包表記を伝えるにはという観点で話を進めました。 まず、リストの内包表記ですが、リストを生成を簡単にしてくれる機能です。 内包表記は、どうやら数学の集合の記法である内包的記法に由来するそうで、「関数プログラミング入門 ―Haskellで学ぶ原理と技法―」か何かで読んだ記憶があります。 その対になる記法として外延的記法

  • GitHub - lstrojny/functional-php: Primitives for functional programming in PHP

    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

    GitHub - lstrojny/functional-php: Primitives for functional programming in PHP
  • 関数型プログラミングを業務開発に適用するための架空の社内勉強会資料 - Qiita

    関数型プログラミングを業務開発で活用するために HaskellやScala、Erlang/Elixir、Clojureなどの関数型プログラミング言語に興味がある人は多いと思いますが、自分らが日常行なっている業務での開発では到底それらの関数型言語を採用できないのが現実、という場合があるかもしれません。 なので、当面はJavaやGroovy、JS,Ruby,Pythonなどの非関数型プログラミング言語の上で関数型プログラミングスタイルや考え方をなるべく使っていくことでFPの考え方や技法に馴染み広めていき、利点を享受しつつ、将来は大手を振って転職業務開発で格的な関数型言語を使えるようにしていこうというのが現実的な戦略かもしれません。 以下はそのような目的での洗脳勉強会をやるための架空の資料の目次(案)のようなものです。 「独自研究」の注意 「FPとは何か」の定義について、現時点で一般に合意のあ

    関数型プログラミングを業務開発に適用するための架空の社内勉強会資料 - Qiita
  • 箱で考えるFunctor、ApplicativeそしてMonad

    モナドについて勉強していて見つけた英語記事を翻訳してみました。 誤訳等あれば編集リクエストやコメントください 原文: Functors, Applicatives, And Monads In Pictures - adit.io ここに単純な値(value)があります。

    箱で考えるFunctor、ApplicativeそしてMonad
  • リアクティブプログラミングとは何だったのか - Qiita

    ※この記事はずいぶん内容がわかりづらかったようで、さまざまな反応を頂きました。追記が複数ありますので、併せてご覧ください。 TL;DR Version: リアクティブプログラミングに挑戦しようとした。がっかりした。 はじめに 私のこの記事は「【翻訳】あなたが求めていたリアクティブプログラミング入門」に触発されて?書かれたもので、そちらの元ネタの記事に先に目を通しておいたほうが理解がしやすいと思います。そちらの記事は当に解説がわかりやすく、そして何よりとても説明が具体的なので、リアクティブプログラミングについて知りたいかたには大変おすすめです。リアクティブプログラミングの解説には、漠然としたことしか言っておらずさっぱり参考にならないものも多いのですが、いや当に多いのですが、この元ネタの記事では図表が適切に使われているだけでなく具体的な問題提起と具体的なコードによる解決策が示されており、リ

    リアクティブプログラミングとは何だったのか - Qiita
  • AffですべてのPromises/Generatorsを過去にする/そして何故我々は作用をモナドで抽象化すべきなのか - Qiita

    PromiseやGeneratorのような機構を使ってもなお非同期処理は厄介だ、そしてもっとシンプルで便利な方法があるよ、という話です。前半の議論を元に、後半ではなぜプログラミング言語の作用をモナドで抽象すると便利なのかということの説明をしています。 関数型プログラミング言語は「副作用をなるべく減らすことで安全性を高めた言語」というように説明されることがありますが、すべての式が副作用を持たないという『純粋』関数型プログラミング言語が言語を参照透明にしてモナドを導入するのは決して「副作用はなるべく避けたほうが安全だから」という理由だけではないのです。長いですが、これでも結構削りました。 序盤戦・Promises/Generatorsの光と影 Promises/Generatorsで世界はちょっと平和になる かつてはJavaScriptの非同期処理はコールバック地獄に陥ったり様々なパターンが混

    AffですべてのPromises/Generatorsを過去にする/そして何故我々は作用をモナドで抽象化すべきなのか - Qiita
  • 仮想DOMを使うのに純粋関数型言語が最適である理由 - Qiita

    『純粋』関数型プログラミング言語といえば関数型プログラミング言語全体のなかでも殊更ラジカルな言語として知られていますが、『すべて純粋』という言語には、『だいたい純粋』という言語にはない利点があります。このテキストは、実感を得やすい具体的な場面を元に『純粋関数型』の利点を紹介していくシリーズです。第一回は言語を純粋にしてモナドで抽象化すると、非同期処理のコールバック地獄をPromise/Generators以上にシンプルかつ優れた方法で解決できるよという話でした。今回は、言語が純粋なら仮想DOMを使うときに純粋性も何も知らなくていいし、レンダリング関数の純粋性が自動的に保証されてとにかく簡単だよ、という話です。 ケース1: 『別に純粋でない』言語~『だいたい純粋な』言語の場合 みなさん仮想DOMは使ってますでしょうか。筆者はもう新しいおもちゃを与えられたイヌのようにハフハフしながら遊んでいて

    仮想DOMを使うのに純粋関数型言語が最適である理由 - Qiita
  • やさしいFunctional reactive programming(概要編) - maoeのブログ

    あと、やはりネットワーク周りなどI/Oの多いプログラムの書きにくさが課題になっている印象。関数的なI/OはFRPで解決できそうな気がするんだけど調べてない。そろそろFRPをちゃんと理解したいなー。 Parsec 3活用事例: Keepalived構文チェッカ - maoeのブログ なんて書いてから早1ヶ月半、ようやくFRPが掴めてきたのでわかったことをまとめてみます。 Reactive programmingって何? FRPの前に、一般的にwikipedia:en:Reactive programmingと呼ばれるパラダイムについて触れておきます。reactive programmingとは疑似言語を使ってかなーり大雑把に説明すると、 var a = 1 var b = a + 1 a = 10 // aを書き換える print b // => 11print bの出力は2ではなく11です

    やさしいFunctional reactive programming(概要編) - maoeのブログ
  • https://www.ediplex.com/blog/?p=830

  • 僕にとってMaybe / Nullable / Optional が、どうしてもしっくりこないわけ。 - 亀岡的プログラマ日記

    はい、ポエムです。自分が正しかろうとは欠片も考えていません。異論や示唆は歓迎ですが、そう考えろと言っているわけではないので、そこはご容赦を。 前置き終わり。 さて、Nullは50億ドルの過ちだそうですね。 null参照の考案は10億ドル単位の過ち? | スラド デベロッパー そして、それを回避するため、Maybe / Nullable / Optional などの言語機能が生まれ、各言語に埋め込まれています。 それは、大変喜ばしいこと、だと思います。 なんですが、どうもどうも、僕はどうしてもしっくりこないのです。これら全てに対して。Nullと同じように。 Nullは何がダメなんだっけ? Nullがダメな理由、ってなんなんでしょう。よく言われる批判として、以下があるのかなぁと思っています。 ①Nullは型ではない Nullと言っていますが、こいつはNullポインタ、でございます。 からの「何

    僕にとってMaybe / Nullable / Optional が、どうしてもしっくりこないわけ。 - 亀岡的プログラマ日記
  • 継続モナドによるリソース管理 - Qiita

    継続モナドって何に使うんだ問題に対する一つの例。 リソース管理の問題 プログラミングをやっていると必ずまとわり付いてくるのがリソース管理の問題です。ここで指すリソースというのは、ファイルのハンドルだとか、ソケットだとか、排他処理のためのロックだとか、グラフィックのハンドルだとかそういう話で、GCのない言語だとメモリの管理もこれに含まれるでしょうか。 言うまでもなく、リソースを確保した後はしかるべきタイミングで確実に解放してやる必要があります。しかし往々にして、現実のプログラムではリソースの解放漏れが発生してしまいます。単に解放するコードを書き忘れると言うのが一番単純でしょうもない理由ですが、それでも、C言語のようにリソース解放のための特別な仕組みを持たない言語では、これを徹底するのも結構骨の折れることだったりします。それはともかく、もう少し高尚な悩みとしては、例外との組み合わせで発生する解

    継続モナドによるリソース管理 - Qiita
  • 関数型・オブジェクト指向なプログラミングパラダイムについて思うところ - 技術memo

    動機 イメージ論でない言語パラダイムに関する話を書きたかった。*1 まともな意見をインターネット空間に1つでも多く残しておきたかった。*2 要約 オブジェクト指向プログラミングはデータに対する操作をオブジェクト*3として抽象化する。 関数型プログラミングでは関数による抽象化を基とする。 言語設計の問題と概念の問題は、混同すべきではない。 オブジェクト指向プログラミング 題材 Consというデータ構造を考えてみます。 Consは任意のデータのペアから成り、その片方をCar、もう片方をCdrと呼びます。 それはJava風に書けば次のようになるでしょう。 public final class Cons{ private Object car; private Object cdr; public void setCar(Object x){ this.car = x; } public voi

    関数型・オブジェクト指向なプログラミングパラダイムについて思うところ - 技術memo
  • http://walk.wgag.net/

  • 関数型プログラミングの今昔(仮)

    函数プログラミングの集いで発表したスライド. 後半についての詳細を知りたい方には, Hudak らの A History of Haskell をお薦めします.

    関数型プログラミングの今昔(仮)
  • 再帰関数のスタックオーバーフローを倒す話 その1 - ぐるぐる~

    再帰関数のスタックオーバーフローを倒す話を何回かに分けてします。 連載目次 再帰関数のスタックオーバーフローを倒す話 その1 ← 今回 CPSとCPS変換の話 再帰関数のスタックオーバーフローを倒す話 その1.5 F#での「末尾」についての話 再帰関数のスタックオーバーフローを倒す話 その2 .NETにおける末尾最適化の方法についての話 再帰関数のスタックオーバーフローを倒す話 その2.5 継続モナドと、F#の残念さの話 再帰関数のスタックオーバーフローを倒す話 その3 すべてをあきらめて再帰をwhileに書き直す方法の話 はじめに 継続渡しスタイルもしくは継続渡し形式(Continuation Passing Style、以降CPS)という言葉を聞いたことがあるでしょうか。 今日はCPSの話をします。 前提知識は、F#のみです。 継続とは CPSの前に、まずは継続の話です。 継続と言って

    再帰関数のスタックオーバーフローを倒す話 その1 - ぐるぐる~
  • 「関数型言語」に関するFAQ形式の一般的説明 - Qiita

    前置き: 特定の言語ではなく、関数型言語一般に関する説明です。 ここに書くのが良いのかわかりませんが、それを考える時間ももったいないのでとりあえず書きます。必要が生じたら移転します。 皆様のご要望や自分の気分(?)により随時加筆修正します。 「それは違うんじゃない?」というご指摘はもちろん、初心者の方の素朴な疑問・質問や、「ここがよくわからない」「こういうことも書いてほしい」みたいなコメントも歓迎します。すぐに対応できない場合もあると思いますがすみません。Twitterのesumii宛でも構いませんが、コメントのほうが他の方も見つけやすくて良いと思います。当然ながら(他者に対しても)誹謗中傷等はご遠慮ください。 いただいたコメントはほぼ文に反映していますので、文を読むために、必ずしもコメントを読む必要はありません。もちろん、興味と余裕(?)があればコメントも読んでいただければ非常に有用

    「関数型言語」に関するFAQ形式の一般的説明 - Qiita
  • 関数型言語を採用するプロジェクトが増加、果たして本当に開発効率は高いのか? | スラド デベロッパー

    ソフトウェア開発に Scala や Haskell、Erlang といった関数型言語を採用する企業が増えているそうだ (ITpro の記事より) 。 関数型プログラミング言語には「迅速に開発できる、バグを抑えやすい、アプリケーションの性能を向上させやすい」といった特徴があるとし、これらは新規のサービス開発に向いているという。「言語選定が競争力に直結」といった意見も記事には掲載されている。 これだけだといいことずくめのようにも聞こえるが、関数型言語は習得しにくく、ライブラリなども C/C++Java と比べるとまだ少ない。使いこなせるプログラマも少なく、関数型言語で大規模システムの設計を行えるエンジニアはまだ少ないのではないだろうか。関数型言語を使える人材はある程度スキルの高い人であり、そのために生産性が高いのではという疑問もある。今後日で関数型言語の採用は進んでいくのだろうか?

  • オブジェクト指向は、シンプルできれいだが脆い。関数型プログラミングは、強く美しいが複雑。F#はいろいろな書き方が混ぜこぜになるよ。楽しいよ。 - Bug Catharsis

    オブジェクト指向プログラミングが好きだ。関数型プログラミングが好きだ。 オブジェクト指向プログラミングオブジェクト指向プログラミングは、コンテナの一般性を確保している点で優れている。 データと振る舞いをコンテナとしてまとめることで、プログラムをわかりやすく整理するという特徴がある。 特定のコンテナ自体を値として別のコンテナに収めたり、操作に対してパラメータ(引数)として受け渡すことでプログラムを表現する。 そのコンテナをオブジェクトって呼んでいる。 データと操作をオブジェクトとしてまとめる利点は、オブジェクトそのものに責務を定義できるからだ。 オブジェクトはそもそも自身の型を知っているので、オブジェクト内のデータによってその状態を識別できる。 カプセル化された実装によって、果たすべき機能が適切に表現される。ただし、オブジェクトで状態を扱うと 必ず副作用を巻き込んでしまうので「脆さ」が見え隠

    オブジェクト指向は、シンプルできれいだが脆い。関数型プログラミングは、強く美しいが複雑。F#はいろいろな書き方が混ぜこぜになるよ。楽しいよ。 - Bug Catharsis
  • シーケント計算と例外処理コード - 檜山正幸のキマイラ飼育記 (はてなBlog)

    先週の土曜に、「晩に渋谷でパスタの会:双対編」を開催しました。例外処理の話をする予定ではいたのですが、当日の朝になって突然シーケント計算と絡めようと思ってしまいました。ところが、シーケント計算の話は最後の15分くらい。ちょっと残念。 ここでは、(コ)パスタの会の文脈は特に仮定しないで、古典論理のシーケント計算が、プログラムの合成や変換と対応付けられることを説明します。包括的な説明ではなくて、二、三の例を出すだけですけどね。でも、その例に関しては詳しく説明します。 内容: とても重要な注意 シーケントと推論図 シーケントと推論図とは何なのか カリー/ハワード対応 例外処理のコードパターン 例外コンバーターをパラメータとする例外処理 どこかで見たような推論規則 それにしても不思議だ とても重要な注意 土曜の晩に、口汚く差別用語を使ってまで強調したことがあります。それは、圏の射を、プログラミング

    シーケント計算と例外処理コード - 檜山正幸のキマイラ飼育記 (はてなBlog)
    unarist
    unarist 2015/02/04
    "圏の射を、プログラミング言語の関数や手続きだと思い込むのはやめてくれ"