タグ

ブックマーク / kazu-yamamoto.hatenablog.jp (19)

  • QUIC開発日記 その1 参戦 - あどけない話

    QUICや ああQUICや QUICや 詠み人知らず。QUICの実装の難しさに絶望した心境が詠まれたと伝う。 序章 2017年の7月ごろ、QUICの実装を始めました。Haskellの有名なシリアライザ/デシリアライザである binary や cereal では、バッファ操作ができないので、パケットヘッダを複雑に処理する必要がある QUIC には不向きです。そこで、Haskell HTTP/2 ライブラリから、バッファ操作の部分を切り出して、network-byte-orderというライブラリを作るところから始めました。 その矢先、上司とのミーティングでのこと: 上司「来年度開発室を立ち上げる前に、下期の半年間、現場に行って開発の現場を見てこい」 kazu「いいですけど、他のQUIC実装に遅れをとることになりますが、いいんですか?」 上司「いい。」 という訳で、QUICの開発は中断されました

    QUIC開発日記 その1 参戦 - あどけない話
    komlow
    komlow 2019/02/13
  • あなたの知らないSemigroupの世界 - あどけない話

    自分で定義するデータの中には、足し算したくなるようなデータがある。たとえば、送信と受信のカウンターを定義したとしよう。 data Metrics = Metrics { rx :: Int , ts :: Int } deriving (Eq, Show) これは以下のように足し算できると嬉しいだろう。 > Metrics 1 2 + Metrics 3 4 Metrics {rx = 4, ts = 6} しかしこれは Num のインスタンスにすべきではない。このデータ型に掛け算は定義できないからだ。かといって、addMetrics みたいな関数を定義するのはかっこ悪い。 > Metrics 1 2 `addMetrics` Metrics 3 4 Metrics {rx = 4, ts = 6} このように演算子が一個だけ欲しいと思ったら、それは多分 Monoid だ。 import

    あなたの知らないSemigroupの世界 - あどけない話
  • TLS 1.3 開発日記 その16 Wireshark - あどけない話

    Wiresharkはv2.3.0からTLS 1.3 draft 19に対応する。めでたい。すぐに使いたい人は、Nightlyビルドをとってくるとよい。 追記:v2.5.0rc0-1840-gd35ed012ce から TLS 1.3 draft 22 に対応している。(draft 22 はまだ出てないけど。) 使ってみる ポート13443で起動しているHaskellサーバとpicotlsクライアントの通信をtcpdumpでキャプチャしたファイルを"pico.pcap"とする。これを表示してみよう。 % tshark -dtcp.port==13443,ssl -Y ssl -r pico.pcap -V Secure Sockets Layer TLSv1 Record Layer: Handshake Protocol: Client Hello Content Type: Handsh

    TLS 1.3 開発日記 その16 Wireshark - あどけない話
  • Haskell から見た node.js - あどけない話

    誤訳 以前、「サーバサイドJavaScriptのNode.js、最初はCやHaskellを検討し失敗。開発者ライアン・ダール氏へのインタビュー」という記事が twitter で話題になっていました。 ―― なぜJavaScriptを選んだのでしょう? ダール氏 実は最初は違いました。最初はC、Lua、Haskellなどで失敗していました。そんなときV8(Chromeが採用しているJavaScriptエンジン)に気がついて、やろうとしていることに対してJavaScriptが完璧な言語だと突然ひらめいたのです。 ただでさえ、Haskell は遅いと誤解されているのに、このような悪意さえ感じらえる訳だと、さらに誤解が深まりそうです。原文にはこう書かれています。 Dahl: Originally I didn’t. I had several failed private projects doi

    Haskell から見た node.js - あどけない話
  • 例題で比較する状態系のモナド - あどけない話

    金曜日に状態系のモナドを説明しないといけないので、例題を書いて比較できるようにしておきます。 呪文として、以下のモジュールを読み込んでおきましょう。 import Data.Char import Control.Monad.Identity import Control.Monad.Reader import Control.Monad.Writer import Control.Monad.State Identityモナド 入力が一つで、出力が一つのモナド。面白みはない。 i :: Identity Int i = do x <- return 2 y <- return 3 return $ x * y でも、モナドは Haskell の中に住むマイクロ言語で、このマイクロ言語でマイクロプログラムを作成した後は、run で実行するものだというイメージは分かるかも。 > runIde

    例題で比較する状態系のモナド - あどけない話
  • モナディック・パーサー - あどけない話

    「ふつうのHaskellプログラミング」や 「構文解析結合子」の元ネタは、どうやら「Monadic parsing in Haskell」のようです。(さらに元ネタは Parsec ですかね。) このオリジナルは、MonadPlus の部分などが古くさいのですが、分りやすいです。というわけで、例題を Parsec 風にアレンジしつつ、勉強してみました。 四則演算式のパーサーを実現することを目標にします。 おまじない 最終的に以下のモジュールが必要になるので、import しておきます。 import Monad import Data.Char Parser の定義 Parser 型の定義はこうなります。 data Parser a = Parser (String -> [(a,String)]) 状態を表すために関数を使っている 関数を使うと状態が表現できることが分らない人は、先に「状

    モナディック・パーサー - あどけない話
  • とりとめのないパーサー談義 - あどけない話

    パーサーに関して、調べたことと疑問を書いておきます。パーサーに詳しい人に答えて頂けると、とても嬉しいです。 チョムスキー階層によれば、以下のような関係が成り立ちます。 正規文法 < 文脈自由文法 < 文脈依存文法 < 制限のない文法 それで、文脈自由文法の中は、こういう関係が成り立ちます。 LL法 < SL法 < LALR法 < LR法 < GLR法 GLR法は、文脈自由文法の全体を解析できる能力を持ちます。 疑問1) GLR法は、文脈依存文法(の一部)も解析できるのか? LL(1) LL(1)に、収まっているのは XML や Lisp です。 LALR(1) LALR(1)に、収まっているのは、ほとんどのコンピュータ言語です。たとえば、C や Java。 GLR GLRに収まっているのは、C++ です。たとえば、D 言語の「テンプレート再訪」には、以下のように文脈がないと比較なのかテンプ

    とりとめのないパーサー談義 - あどけない話
  • Haskell の Monad とは言語内DSLのフレームワークである - あどけない話

    この記事は、Haskellを勉強してある程度分かったけど、Monadで挫折した人のための記事です。10分間で、Monadに対する納得感を得ることを目的としています。他の言語でいう「モナド」にも通用する内容ですが、Haskell の文法や用語を用いますので、他の言語の利用者に分かるかは不明です。 Haskellを勉強したのですから、 代数データ型 型クラス は分かっていることにします。Monad は、単なる型クラスの一つで、それ以上でもそれ以下でもありませんから、この二つが分かってないと話になりません。 また、言語内DSL(以下、DSLと略記)という考え方を知っていることも仮定します。Monad とは、DSLのフレームワークという直感を与えるのが、この記事の主眼ですからね。 さらに、構造化定理をいう単語を聞いてもビビらない人を想定しています。逐次、反復、分岐があれば、計算しうる計算はすべて記

    Haskell の Monad とは言語内DSLのフレームワークである - あどけない話
  • Haskellには副作用がないのか? - あどけない話

    ある人は、Haskell には副作用がないと言う。また、別のある人は Haskell には副作用があると言う。Haskell を学ぶ者にとって、こういった意見のい違いが、Haskell を得体の知れない言語にし、学習の障壁となっているかもしれない。そこで、この記事では、なぜこのような意見の相違が生まれるのかについて説明したいと思う。 向心力か遠心力か? 僕は高校三年になって受験勉強をするまで、物理の運動方程式が得体の知れないものに思えていた。 例として円運動を考えよう。ある説明では、円運動をしている物体には向心力が働いていると説明されている。また別の説明では、遠心力が働くと説明されている。一体、どういうことだろう? 受験勉強でたくさんの問題を解いて、ようやく分かった。これらの説明はどちらも正しい。すなわち、観測者がどこにいるかによって、説明の仕方が異なるのだと。 観測者が円運動をする物体

    Haskellには副作用がないのか? - あどけない話
  • Haskell Relational Record をリリースしました - あどけない話

    Haskell Relational Record (HRR)尻叩き担当の山です。この記事では、HRR のリリースについて説明します。 なお、これは Haskell Advent Calendar 2014 の25日目の記事です。 HRR とは何か? HRRは、日比野さんが中心となって開発が進められている関係代数ライブラリです。Haskellで式を書くと、それがSQL文に変換され、データベースに問い合わせた結果が Haskell のレコードになります。以下のような特長があります。 抽象的:高レベルな式で表現すると、SQLが生成されます。対応している SQLサーバは、DB2、ProsgreSQLSQLiteMySQLMicroSoft SQL Server および OracleSQL です。 型安全:HRRの式を書いたHaskellのコードがコンパイルできれば、必ず正しいSQL文が生

    Haskell Relational Record をリリースしました - あどけない話
  • 状態モナド遊び - あどけない話

    状態をモナドで実現する方法を考えます。 リスト 例は簡単な方がいいので、データ構造として Lisp 風のリストを定義しましょう。 data List a = Nil | Cons a (List a) deriving Show リストは、こんな風に表せます。 Cons "c" (Cons "b" (Cons "a" Nil)) Lisp 風の cons も定義してみましょう。 cons :: a -> List a -> List a cons x xs = Cons x xs cons "c" $ cons "b" $ cons "a" Nil → Cons "c" (Cons "b" (Cons "a" Nil)) 状態を持つリスト さて、この Lisp 風のリストに、要素の数を覚えさせておきたいとしましょう。もちろん、数えれば分りますが、数えなくても一瞬で分るようにしたいのです。

    状態モナド遊び - あどけない話
  • Lensことはじめ - あどけない話

    見ろ! Haskell が OOPL のようだ! さてさて、ようやく重い腰を上げて、Lens を勉強し始めましたよ。Haksell for allを見て勉強すればいいのかなと思ったんですが、解説しているパッケージが data-lens なので古いですね。 今、使うべきなのは、lens というパッケージらしいです。解説は、この README を読むのが一番だそうです。この README と Haskell for all をにらめっこしながら、Lens の getter と setter の機能を使ってみます。 背景 Haskell の代数データ型にはフィールドラベルが定義できて、これがいわゆる getter と setter の役割を果たします。Haskell for all から例を引用してみましょう。 data Point = Point { x :: Double , y :: Do

    Lensことはじめ - あどけない話
  • Applicativeのススメ - あどけない話

    この記事の目的は、Applicative 信者による Applicative スタイルの布教です。 簡潔に結論を述べると、 foo = do a <- m1 b <- m2 return (f a b) のようなコードを書きたくなったら foo = f <$> m1 <*> m2 と書きましょうということ。 合い言葉は、「do と return をなくせ!」です。 FunctorとMonadの間 Functor を特殊化した型クラスがMonadで、Monadの方が強力です。なぜなら、メソッドが増えるからです。 Functorのメソッドはfmapです。fmapの別名を (<$>) といいます。(この記事では、(<$>) と liftM を同一視します。) そして、Monadのメソッドは、ご存知の通り (>>=) と return です。 FunctorとMonadの間にApplicative

    Applicativeのススメ - あどけない話
  • Real World Haskell の古いところ - あどけない話

    Real World Haskell の内容が古くなってきたので、どこが古いかとか、それに変わる新しいものは何とか、まとめたいと思う。 Real World Haskell―実戦で学ぶ関数型言語プログラミング 作者: Bryan O'Sullivan,John Goerzen,Don Stewart,山下伸夫,伊東勝利,株式会社タイムインターメディア出版社/メーカー: オライリージャパン発売日: 2009/10/26メディア: 大型購入: 8人 クリック: 245回この商品を含むブログ (76件) を見る 1章 始めましょう 今でも通用する。 2章 型と関数 今でも通用する。 3章 型を定義し、関数を単純化する 今でも通用する。 4章 関数プログラミング ghc に --make オプションはもう不要。 5章 ライブラリを書く 5.14節では、"runghc Setup build" の

    Real World Haskell の古いところ - あどけない話
  • Haskell のデータ構築子 - あどけない話

    Haskell の代数データ型で使われるデータ構築子は、実は関数と同様に扱えます。たとえば、四則演算の式を表す代数データ型を以下のように定義したとします。 data Expr = C Int | Add Expr Expr | Sub Expr Expr | Mul Expr Expr | Div Expr Expr deriving Show "1 + 2" は "Add (C 1) (C 2)" と表現できます。この式を評価してみましょう。 Add (C 1) (C 2) → Add (C 1) (C 2) 当たり前ですが、そのものが返ってきます。 話は変わりますが、add という関数を素直に定義すると、こうなるでしょう。 add x y = x + y 式 "add 1 2" を評価するとこうなります。 add 1 2 → 3 すなわち、関数であれば簡略化されますが、データ構築子であ

    Haskell のデータ構築子 - あどけない話
  • Git に関する良記事 - あどけない話

    適宜追加します。 Pro Git 僕が読んだ Git の書籍の中では、一番分かりやすいと思いました。日語版の書籍はありませんが、オンライン版が翻訳されています。 Pro Git 図解 Git Git の初心者が動作を理解するのにおススメ。 図解 Git こわくない gitランチとマージの考え方がよく分かるスライド(@methaneさんから教えて頂きました)。 こわくない git あなたの知らないGit Tips 書籍には載ってない Tips の解説。知らないと損するかも。 あなたの知らないGit Tips ワークフロー、あるいはブランチング チームでブランチを使う際の取り決め。自分のチームで一から議論するより、すでにあるものを参考にしましょう。 git-flow github-flow Github Enterprise Github Enterprise は、企業内に設置して使うこ

    Git に関する良記事 - あどけない話
    komlow
    komlow 2013/04/02
  • コンパイルは(テストではなく)証明である - あどけない話

    「プログラムのテストはバグの存在を示すことにかけてはとても効率的な方法ですが、バグの不在を示すことにかけては絶望的なほどに不適切です。プログラムの信頼性を顕著に向上させる唯一の方法は、その正当性に対して説得力のある証明を与えることです」 -- Edsger W. Dijkstra 静的型付き言語では、コンパイル時に型が検査される。この型検査に関連して型推論という機能を持つ言語がある。型推論は、大きく分けて2つの意味で使われているようだ。 命令型言語の多くに見られる型推論:型検査の過程で、省略された型を補うこと 関数型言語の多くに見られる型推論:未知の型を変数として方程式を立て、方程式を解いて未知の型を求めること。型推論自体が型検査の役割を果たす この記事では、後者の型推論を話題にする。 静的型付き関数型言語の利点として、よく「コンパイルはテストである」という説明がなされる。プログラムは式で

    コンパイルは(テストではなく)証明である - あどけない話
  • 静的型付き言語プログラマから見た動的型付き言語 - あどけない話

    およそ20年前にAlan Kay の講演をきいたことがある。印象に残ったのは、彼が引き合いに出した McLuhan の言葉だ。 I don't know who discovered water, but it wasn't a fish. (拙訳)誰が水を発見したかは知らないが、発見者が魚でなかったことは確かだ。 誰しも信念という水の中を泳ぐ魚のような存在だ。思い切って飛び跳ね空気に触れてみなれば、自分が信念という水の中にいることに気付かない。 ある手法の利点を語るには、その手法の欠点や、他の手法の利点や欠点とできるだけ客観的に比較しなければ説得力がない。ただ、これを実践するのは難しい。この記事では、客観的になれているか自問自答しながら、動的型付き言語と静的型付き言語について比較してみようと思う。 僕は静的な C 言語から、動的な Perl、Lisp、JavaScript を経て、現在で

    静的型付き言語プログラマから見た動的型付き言語 - あどけない話
  • カリー化談義 - あどけない話

    最近、スタートHaskellで「カリー化された関数のメリットは何か?」という質問が出た。そのすぐ後に、kmizuさんがカリー化の誤用に対して警鐘を鳴らしてしていた。僕からするとkmizuさんの「カリー化の定義」も誤用に思えたので、調べるとともに考えたことのまとめ。 いろんな定義 「カリー化する」という用語は、すくなくとも以下の3つの意味で使われているようだ。 部分適用という意味 これは明らかに間違い 「複数の引数を取る関数」を「一引数を取る関数のチェインに直す」こと これはkmizuさんの定義。世間でもよく使われる。 「構造体を一つ取る関数」を「構造体のメンバーを複数の引数にばらし、一引数を取る関数のチェインに直す」こと これは僕の定義。というか、Haskellコミュニティの定義。 「部分適用」の意味で使うのは明らかに間違いのなで排除。定義2と3について議論する。あとで、部分適用とは何かに

    カリー化談義 - あどけない話
  • 1