単純で頑強なメッセージングシステム、franz - モナドとわたしとコモナド
Haskell製の新しいメッセージングシステムfranz(フランツ)の紹介。 github.com 背景 取引所にあるマシンで取引プログラムを実行するのが我々の仕事だが、朝8時に起動したらあとは昼寝したり酒を飲んだりというわけにはいかない。モニタリングしたり、分析のためにデータを残しておく必要がある。そのため、プログラムによって解析しやすい形でログを出力する。 今までは複数の種類のレコードをシリアライズし、一つのファイルに連結させる独自のフォーマットを10年近く使っていたが、書いていて恥ずかしくなるような多数の問題を抱えていた。 柔軟性が乏しい: 32bit整数や文字列などの単純な値しか格納できず、例えばレコードを含むレコードなどを表現できない。その結果、複雑なデータは一旦文字列に変換するような運用がされており、そのプリティプリンタやパーサは十分にテストされていない。 コードがまとまってい
就職しました - モナドとわたしとコモナド
本日、Tsuru Capitalのポジションを得ました。 Tsuru Capitalはデリバティブの取引を行っている企業で、自動株取引の会社ではありません。取引に関わっている10人のメンバーのうち、創始者であるSimonを除く全員がHaskellerで、取引状況の分析や一部の取引の自動化など、あらゆるところにHaskellを使っているのが大きな特徴です。日本では数少ない、Haskellをメインに使っている企業の一つでもあります。 東京、シンガポール、バンクーバーにオフィスがあり、東京には私を含む5人の開発者と事務担当、Simonと愛犬テトがいます。 オフィスはオランダヒルズ森タワーRoPにあります。設備が非常に充実しており、東京に引っ越すまではオフィスに週数度の頻度で泊まっていました。風呂上がりにジンジャエールをラッパ飲みしながらサーバールームの熱風で体を乾かすと、すごく気持ちが良いです。
モノイドと継続渡しの道具箱 - モナドとわたしとコモナド
関数型言語Haskellにおいて、普通は計算の結果は関数の戻り値として扱うが、「結果を受け取る関数」 に渡すという継続渡しというスタイルもある。これは単なる冗長なやり方ではなく、様々な興味深い性質を持つ。 基本形は、aという値を渡すところを ∀r. (a -> r) -> r のような表現にする。たとえば、与えられた数の42倍を渡したいとき、そのまま\x -> x * 42ではなく、\x f -> f (x * 42)と書く。もちろんこれだけではありがたみが分からない。 さて、与えられた文字列の中のうち、大文字のアルファベットを取り出し、それがアルファベットの何番目か計算するプログラムを作りたい。普通はリストを使ってこのように書くかもしれない。 import Data.Char uppers :: [Char] -> [Int] uppers [] = [] uppers (x:xs) |
出、出～～ｗｗｗｗｗ銀行員待行列解説奴～ｗｗｗｗｗｗｗ - モナドとわたしとコモナド
銀行員待行列(Banker's deque)、二つのリストで構成奴～～ｗｗｗｗｗ 入奴と出奴～ｗｗｗｗｗｗｗｗｗ ↓入奴 三(^o^)ノ [(^o^)ノ, (^o^)ノ, (^o^)ノ] ヽ(^o^)三 [ヽ(^o^), ヽ(^o^), ヽ(^o^)] ↑出奴 追加は入奴にcons、取り出しは出奴にuncons奴～ｗｗｗリストなので基本定数時間奴～ｗｗｗｗｗｗ リスト枯渇防止の為、リストの長さに以下の条件課奴～～～ｗｗｗｗｗｗ length (入奴) <= length (出奴) * 3 + 1 length (出奴) <= length (入奴) * 3 + 1 条件充足不能場合、|length (入奴) - length (出奴)| <= 1なるよう余剰分反転後短い側の末尾に結合して調整奴～ｗｗｗｗｗ時間計算量O(length (入奴) + length (出奴))必要～～～～ｗｗｗｗ
ぼくのかんがえた最強の拡張可能レコード - モナドとわたしとコモナド
注意(2018/04) かなり古い記事なので、extensibleの最新のバージョンとはまったく互換性がない __ 動機 GHCに、OverloadedRecordFields(ORF)という拡張の導入が提案されている。 (Records/OverloadedRecordFields/Design – GHCより) Haskellのレコードの深刻な欠点は、フィールドをオーバーロードできないことだ。例えば、 data Person = Person { personId :: Int, name :: String } data Address = Address { personId :: Int, address :: String } と定義したとき、personIdはどちらを参照すべきかわからない。よくある対策としてデータ型に接頭辞をつけるという方法があるが、コードやフィールド間の関
副作用の話 - モナドとわたしとコモナド
最近、副作用や関数型言語についてもめているのをよく目にする。副作用と関数型言語に関する私の見解をここに示す。 処理系はソースコードを解釈し、コンピュータの入出力、つまり副作用に変換する。ほとんどのプログラミング言語は、副作用を表現するプリミティブとその組み合わせによってプログラムを記述する。副作用は実行時に生まれるものだから、「Cの関数は副作用がある」「Haskellのコードに副作用はない」といった議論は、残念ながら意味をなしていない。実行していないのに副作用が出てきたら、超自然的な力を信じざるを得ない。 副作用の扱いについてよく議論の的になる言語としてHaskellがある。Haskellが多くの手続き型言語と異なるのは、副作用を含む計算に対して、専用の型(IO)が定義されているというだけであり、「そのコードが副作用を記述できるかどうか」を区別しやすくするためのちょっとした助けに過ぎない。
オブジェクト指向関連の不満な点 - モナドとわたしとコモナド
また遅れてしまった…オブジェクト指向 Advent Calendar11日目。 最近いろいろオブジェクト指向について調べていて、やっぱりこの概念はいかがなものか、と思ったことを軽く書く。 継承 まずこれ。オブジェクト指向において「AがBを継承している」というのは、外延的には「任意のBのメソッドはAのメソッドである」であり、実装としては「AはBが持つ内部状態やメソッドの実装を利用できる」ことが多い。しかし、Twitterにも似たようなことを書いたが、「車クラスが乗り物クラスを継承している」みたいなゆるふわな使い方が目立つ。クラス、インターフェイスの用語と、それらの継承の定義ははっきりさせたい。則のない関係に意味なし。 抽象クラス、抽象メソッド 実装のない「抽象メソッド」と実装のあるメソッドをごちゃ混ぜにできるような仕様は害があると考えている。インターフェイスがあるにもかかわらずこのような中途
関数型プログラミングとオブジェクト指向の抜き差し可能な関係について整理して考える - モナドとわたしとコモナド
Googleで適当に検索すると とズラリと出てくる。 オブジェクト指向 v.s. 関数型プログラミング 関数型とオブジェクト指向という一見相反するプログラミングパラダイムの併用について理解した プログラマが知るべき97のこと/関数型プログラミングを学ぶことの重要性 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 関数型プログラミングとオブジェクト指向の抜き差しならない関係について整理して考える とそれなりに参考になりそうな情報はあるものの、無駄に複雑化されたオブジェクト指向をストローマンにするような記事ばかり(それだけ今までのオブジェクト指向にみんなうんざりさせられているのだろう)で、そろそろきちんと自分自身「関数型プログラミングとオブジェクト指向の切り離され方」についてはっきりさせておきたい、と考え、概念整理した結論を書きます。 まず端的な結論 結論を
Haskell Advent Calendar 13日目: シンセサイザーで理解するArrowプログラミング - モナドとわたしとコモナド
Haskell Advent Calendar 13日目の記事です。 ごきげんよう。 今年も音楽の冬がやってまいりました。Haskellより音楽のほうに力を注いでいる気がするこの頃ですが、ふとこう思いました――「Haskellでシンセサイザーを作たらとても楽しいのではないか？」 シンセサイザーの仕組みは、たとえばFM・減算式ならこうなります: しかし、これが実装出来てもあまり嬉しくない、というのはわかっていただけるのではないでしょうか――そう、ただのシンセサイザーではなくどんなシンセサイザーでも作れるフレームワークが欲しいのです。 部品を作る部品 -Artery- まず、私は、部品同士を「配線」できるようにするため、arteryというパッケージを作りました。 ArteryはArrowとしてのインターフェイスを持っています。Arrowはごく簡単に表現すると、以下のようなクラスで表現されます(
モナドとはモナドである - モナドとわたしとコモナド
この記事を読む前に、絶対に理解出来ないモナドチュートリアルに一度目を通してみてほしい。モナドを理解していく上で、とても重要なことが書かれている。 改めて言おう、モナドはモナドだ。コンテナだとかプログラマブルセミコロンだという説明では、モナドのすべてを正確に表せるとは言い難い。では、モナドを過不足なく説明できる、モナド以外の言葉はあるのか？ 実は、モナドを表現し、かつモナドで表現される言葉は存在する。その一つは手続きである。手続き型言語の「手続き」だ。 手続きとは何か 手続きは結果を持つ おおよそすべての手続きは何らかの結果を持つ。Haskellの()、C言語のvoid、PythonのNone、Rubyのnilなども結果の一種だ。結果が出ないとしたら、そのプログラムは停止しないか、途中で異常終了するだろう。 手続きには最小単位が存在する 処理系が扱っている以上、手続きが際限なく分解できるとい
モナドの六つの系統[Functor x Functor] - モナドとわたしとコモナド
モナドは「アクション」を表す抽象的な構造である。モナドは、Haskellにさまざまな概念に対する記述能力をもたらす。 モナドの基礎 return :: a -> m a: 純粋な値をモナドで包む。 m >>= f :: m a -> (a -> m b) -> m b: モナドmに包まれた値をfに渡し、その結果として現れたモナドを結合する。 固有アクション: それぞれのモナドに固有の方法でモナドを生み出す。 実行: モナドに包まれた値を、より根源的な形に還元する。 モナド則 モナドに以下の三つの制約を課すことによって、最低限度の記述能力を保証している。 return a >>= k == k a m >>= return == m m >>= (\x -> k x >>= h) == (m >>= k) >>= h より強い制約は、より強い力を生み出す。 モナドの分類 モナドは、以下の6つ
![モナドの六つの系統[Functor x Functor] - モナドとわたしとコモナド](https://cdn-ak-scissors.b.st-hatena.com/image/square/7eb5625f5d2ec1583e200191f6946dfd3a14d883/height=288;version=1;width=512/http%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Ff%2Ffumiexcel%2F20130605%2F20130605170915.png)
Freeモナドを超えた！？operationalモナドを使ってみよう - モナドとわたしとコモナド
限定版IOみたいなモナドを簡単に作れたら、コードが分離できるしテストもしやすくなるのになあ… 数か月前なら、 それ、Freeモナド*1でできるよ！ と返されるだろう。だが今は違う。Freeモナドよりも簡単にモナドを作れるモナド、Operationalモナドがあるのだ。 Freeモナドについて復習しよう。FreeモナドはFunctorを基にMonadを作れる構造であり、Functorで自分自身を包むことによってモナドの力を得ている*2。FunctorそのものはDeriveFunctor拡張を使って簡単に作れる。 {-# LANGUAGE DeriveFunctor #-} import Control.Monad.Free data CharIO a = PutCh Char a | GetCh (Char -> a) | LiftIO (IO a) deriving Functor put
Indexed Monadの世界 - モナドとわたしとコモナド
もっと、モナドの力を引き出したくはないか？ え？アクションの前後で型を変えたい？いやいやいや、モナドは自己関手の圏上の単なるモノイドだよ、そんなことができ…る…！？えっ、できるの…マジで…？ できる。そう、Haskellならね。 {-# LANGUAGE QuasiQuotes #-} import Control.Monad.Indexed.State import Control.Monad.Indexed import Language.Haskell.IndexedDo hoge :: IxState Int [Int] () hoge = [ido|do imodify (*10) imodify show imodify reverse imodify (++"123") imodify $ map fromEnum |] *ghci> runIxState hoge 42 (
そろそろFreeモナドに関して一言いっとくか - モナドとわたしとコモナド
Freeモナドはすごい。 Haskellを書いていて、「特殊化された処理を記述するモナドが簡単に作れたら便利だろうなー」と思ったことはないだろうか？簡単に作れるのである、そう、Haskellならね。 これが、純粋なFreeモナドの定義である。 data Free f a = Pure a | Free (f (Free f a)) instance Functor f => Monad (Free f) where return = Pure Pure a >>= k = k a Free fm >>= k = Free (fmap (>>=k) fm) (Functor、Applicativeのインスタンス宣言は自明なので省略) 与えられたFunctorをお互いに埋め込み合っている、という漠然とした印象で、何が嬉しいのかよくわからないかもしれない。だが、この単純さこそFreeモナドの便利
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
