Haskell モナド変換子 超入門 - Qiita
Haskellではモナドと呼ばれる部品を組み合わせてプログラムを作ります。別種のモナドを組み合わせるためのモナド変換子の使い方の初歩を説明します。ライブラリで用意されたモナド変換子を手っ取り早く使うことを目的としているため、モナド変換子の作り方や圏論には言及しません。 シリーズの記事です。 Haskell 超入門 Haskell 代数的データ型 超入門 Haskell アクション 超入門 Haskell ラムダ 超入門 Haskell アクションとラムダ 超入門 Haskell IOモナド 超入門 Haskell リストモナド 超入門 Haskell Maybeモナド 超入門 Haskell 状態系モナド 超入門 Haskell モナド変換子 超入門 ← この記事 Haskell 例外処理 超入門 Haskell 構文解析 超入門 【予定】Haskell 継続モナド 超入門 【予定】Has
圏論とかモナドなんて簡単だからscalaを使って説明してみた - だらだらしてたいなぁ
はじめに 関数型といえばモナド、モナドといえば難しいという事が巷で言われていますが、いきなりモナドを理解しようとするから難しく思えるだけで、圏論から順序を追って理解していけば全然難しく無いんだよって事を分かって貰えればいいなぁと思い書いて見ることにしました。 ただ、圏論といっても適用範囲がとっても広く、応用編になると分けわかんなくなってくるので、ここではプログラミング分野に特化したFP(functional programing)圏論*1について書きます。 また、説明を簡単にする為に細かい部分をいろいろ省略しています。学術的な定義としては正確ではないので、このエントリの説明は大体合ってる位の気持ちで読んでくださいね。 尚、ぼくは圏論の詳しい事はさっぱり分からないので、学問的な話を振られても回答できませんｷﾘｯ 圏ってなんなの？ 圏論と言えば、圏です。 圏って何なのかというと、対象(obje
Stateモナドがわかればモナドがわかる - セカイノカタチ
この記事は、Haskell Advent Calendar 2014 23日目の記事です。 僕自身が、駆け出しHaskellerなのであまり難しいことは書けません。きっと中級以降の人には常識的な話題で「何を今更・・・何周遅れだよ(´・ω・`)」みたいな微妙な話ですが、お付き合いください。 しかし、Haskellと言うとモナドみたいな風潮は何とかならんのか・・・。 なりません！(｀・ω・´)ｼｬｷｰﾝ モナドにも種類がある ということで、モナドの話です。 モナドというのは、Monadという型クラスです。型クラスというのJavaで言うとインターフェースのようなものです。 これを実装した上で、モナド則と言われる規則をクリアし、厳しい試練に耐えぬいた型だけがMonadになれます。大変ですね。 例えば、こんな型がモナドとして知られています。 Maybe [] Identity Either Stat
slick-doc-ja 3.0 — ORMからSlickを利用する人へ
Slick 3.0.0 documentation - 11 Coming from ORM to Slick Permalink to Coming from ORM to Slick — Slick 3.0.0 documentation ORMからSlickを利用する人へ Introduction Slickは、Hibernateや他のJPAベースのプロダクトのようなORM（object-relational mapper）では無い。SlickはORMのようにデータを永続化させるソリューションの1つであり、いくつかのコンセプトは共有しつつも、大きな違いがいくつかある。本章ではSlickのメリットについての理解を手助けしつつ、ORMとの違いについて順に説明する。object-relationalなものに対して言及される様々な問題（object-relation-impedance mi
FutureとEitherの話の続き(ApplicativeとMonadの違い) - xuwei-k's blog
昨日書いたこれ ScalaでFutureとEitherを組み合わせたときに綺麗に書く方法 の中で、 実は今回の例だけだと、Applicativeの範囲でいけるので、必ずしもモナドトランスフォーマーは必須ではありません と書いたところ、以下のような反応をもらったので Applicative でダメな例気になる 2014-09-20 00:08:37 via Twitter for Websites 例を思いついたので、それも書いておきましょう。丁寧にScalaz初心者向けに説明するの疲れたので、以前よりは雑に要点だけ書きます、ご了承ください。今回も先にコード例のgist貼っておきます。 https://gist.github.com/xuwei-k/051c3b00129b7a0dfcd6 そもそも「Applicativeで範囲よい」「ApplicativeではダメでMonad必要」は、モナ
モナドの本当の力を引き出す・・・モナドによる同期/非同期プログラミングの抽象化 - xuwei-k's blog
以下の2つの続き ScalaでFutureとEitherを組み合わせたときに綺麗に書く方法 FutureとEitherの話の続き(ApplicativeとMonadの違い) 上記の2つ(特に最初の方)を読んだことを前提で書くので、読んでない人は先にそちらを読みましょう。 なんだか少し関連する話(?)で盛り上がっていて、書かないといけない気がしてきたので 非同期プログラミングの難しさとScalaのFuture そのtogetterの議論について色々書きたいこと*1もありますが、それは置いておき、表題の「モナドによる同期/非同期プログラミングの抽象化」について書きます。というか、(非同期プログラミングの話より)便乗してモナドとモナドトランスフォーマーの便利さを話したいだけかもしれません(?) 前回2つは「Future使って非同期にしても、だいたい関数の本体同じでいけるよ」ということを書きました
ScalaでFutureとEitherを組み合わせたときに綺麗に書く方法 - xuwei-k's blog
組み合わせるとはつまりアレのことを書くのですが、一応それほど前提知識無くても理解できるように書いてみます。さて、なぜいきなりEitherとFutureか？というと play2とか使ってると、Futureがよく出てくる Futureをそこら中でAwaitしたらFuture使う意味がないので、Future[A]をmapやflatMapなどでどんどん連鎖させて、メソッドの型にFutureが大量に出現！ Futureは非同期に行われる処理であり、そこで例外発生したら、その中に例外を含むしかない(単純に例外投げるわけにはいかないというか不可能) Scala標準ライブラリのFutureは、Throwable型で例外を保持できるようになってる 逆にいうと、Throwableでしか保持できない 例外の種類が多くなってきて、プログラムが複雑になった場合、Throwableではなくもっと限定された独自のエラー
DBから単一SELECTする関数の型をFuture[何]にすれば良いのか悩む - Qiita
プロジェクトで一つの書き方に統一したくて悩んでいる。ちなみにまだどれも実際に使ったことがないので下の感想は想像レベル。 Future[Option[...]]派 良いところ 同期バージョンの型をOption[...]にしていたらFuture[Option[...]]にするのは比較的考えることが少なそう 複数取得するときの型をFuture[List[...]]にするとmapとかの見た目上対称性のあるコードになりそう（？） 悪いところ コードが煩雑になりがち 2つの型クラスに包まれているとforを使いにくい repository.resolveAsync(id).map { maybeRecord => maybeRecord.map { ... } } Future[Either[...]]派 play2とか使ってると、Futureがよく出てくる Futureをそこら中でAwaitしたらFu
![DBから単一SELECTする関数の型をFuture[何]にすれば良いのか悩む - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/ed081d5cc0a28956bf0abc2291a60599383a025f/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9REIlRTMlODElOEIlRTMlODIlODklRTUlOEQlOTglRTQlQjglODBTRUxFQ1QlRTMlODElOTklRTMlODIlOEIlRTklOTYlQTIlRTYlOTUlQjAlRTMlODElQUUlRTUlOUUlOEIlRTMlODIlOTJGdXR1cmUlNUIlRTQlQkQlOTUlNUQlRTMlODElQUIlRTMlODElOTklRTMlODIlOEMlRTMlODElQjAlRTglODklQUYlRTMlODElODQlRTMlODElQUUlRTMlODElOEIlRTYlODIlQTklRTMlODIlODAmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZ0eHQtY2xpcD1lbGxpcHNpcyZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTI5Yjg3YmZkYzc4NGI0YTQ2MmMyMGEzNTE2YzhhNmU3%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwZWR2YWtmJTQwZ2l0aHViJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz03MGY3M2M2ZmIwZTE1MWFhYmM0OTE1YTc2YTMzZDljNg%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3Dfe43a6abcd7f75426bd48b01f254be0f)
非同期プログラミングの難しさとScalaのFuture
Toshiyuki Takahashi @tototoshi @edvakf 2つめはFuture[Either[E,T]] 派というかモナドトランスフォーマー派だと思いました。この場合はEitherTじゃなくてOptionT使うと思います。 2015-03-26 10:30:37 Toshiyuki Takahashi @tototoshi @edvakf Scalaだとモナドトランスフォーマーそんな一般的ではないので普通の人は妥協して、もしくはそういうものとして最初の形にすると思います。最後のやつはIOとして想定しているのがDB以外もある気がしてなんとも言えないですが、よく見るパターンではないです。 2015-03-26 10:32:27 Toshiyuki Takahashi @tototoshi @edvakf あと別の話で、asyncなドライバー使ってない限りJDBCはブロックす
独習 Scalaz — 独習 Scalaz
独習 Scalaz これまでいくつのプログラミング言語が羊の衣を着た Lisp に喩えられただろうか? Java は馴染み親しんだ C++ のような文法に GC を持ち込んだ。それまで他にも GC を載せた言語はあったけども、現実的に C++ の代替となりうる言語に GC が載ったことは 1996年には画期的に思われた。やがて時は経ち、人々は自分でメモリ管理をしないことに慣れていった。JavaScript と Ruby の両言語もその第一級関数 (first-class function) やブロック構文を持つことから羊の衣を着た Lisp と呼ばれたことがある。S式の同図像性がマクロに適することから Lisp系の言語はまだ面白いと思う。 近年の言語はもう少し新しい関数型言語から概念を借りるようになってきた。型推論やパターンマッチングは ML にさかのぼることができると思う。時が経てば、人
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
