はてなブックマーク

これはHaskell Advent Calendar 2023の19番目の記事です。 フォーマッター 以前、フォーマッターをいくつか試しましたが、どれもイマイチでした。しかし、fourmoluはいけてます。fourmoluは、Ormoluのフォークで、Ormoluが偉大なのでしょう。両方試しましたが、僕はformoluに決めました。 Hackageに上がっているので好きな方法でインストールしてください。 % cabal install fourmolu formoluにHaskellのプログラムを渡すと、整形したプログラムを出力してくれます。ファイルの内容を直接書き換えたいときは、-iオプションを渡します。エディタやIDEと連動できますが、お試しでプロジェクト全体を整形するには、以下のようにするといいでしょう。 % find . -name "*.hs" | xargs fourmolu

これは、Haskell Advent Calendar 2021の2日目を埋めるために書いた記事です。実は単に僕が作った「関数プログラミングの入門」の資料の宣伝です。 ちなみに、僕の関数プログラミングの定義は「不変データプログラミング」であり、おそらく最も厳しい定義です。なので内容が分かれば、関数プログラミングに入門できた言ってもよいのではないかと思います。 関数プログラミングことはじめ 僕は毎年、岡山大学の三年生に向けて、2コマで関数プログラミングを教えています。その資料が、「Cプログラマーのための関数プログラミングことはじめ」です。岡山大学工学部情報系学科の学生は、C言語を習っているので、C言語に似た文法を独自に定義して、関数プログラミングを説明しています。 ［入門］関数プログラミング ［入門］関数プログラミングは、WEB+DB PRESS Vol.67に掲載された記事です。編集部のご

これは、Haskell Advent Calendar 2021 の8日目の記事です。 Haskellのコンパイラとして事実上一択となったGHCには、「軽量スレッド」が実装されています。軽量スレッドは、ネイティブスレッドよりも軽量なスレッドで、他の言語では「グリーンスレッド」とも呼ばれています。Haskellerが並行プログラミングをするときは、軽量スレッドを息を吸うかのように使います。 複数の軽量スレッドの入出力を束ねるのが、IOマネージャです。IOマネージャも単なる軽量スレッドであり、OSから入出力のイベントを受け取り、それぞれの軽量スレッドにイベントを通知します。 軽量スレッド(っぽい)機能を提供する他の言語では、GHCのIOマネージャを参考にしているようです。僕はIOマネージャの開発に深く関わっています。この記事ではIOマネージャの歴史をまとめるとともに、主にmacOSでの実装に関

My open server of Haskell QUIC on Linux sometimes got segfaults. I saw two types of segfaults. One is a simple segfault by accessing a wrong address: mighty: segmentation fault The other is relating to free(): *** Error in `mighty': corrupted double-linked list: 0x00007fcdf0008f90 *** I guessed that a buffer overrun occurred against a buffer allocated by malloc() and this segfault happened when th

For last two months, I have been trying to implement "QUIC Loss Detection and Congestion Control" in Haskell. This blog article describes a brief summary on what I have done. ACK handling Before loss detection and congestion control were developed, QUIC packets were retransmitted, if necessary, by a simple resender lightweight thread based on timeout. The internal data structure was, of course, Pr

QUICは、一年半実装を続けている僕でも全容を把握できているとは言い難いほど大きなプロトコルですが、ある側面をさっと理解するには、n月刊ラムダノート Vol.2, No.1(2020)に西田さんが書かれた「パケットの設計から見るQUIC」がオススメです。ただ、QUICの専門家から見ると、若干不正確な部分がありますので、訂正すべき箇所をまとめておきます。(遅くなって、すみません。) 記事を公開することは西田さんにお知らせしていますが、ここに書いてある内容はあくまで僕の意見です。 最初のページ 「QUIC(Quick UDP Internet Connections)は、インターネットのアーキテクチャ 上で利用可能な、高い信頼性を提供する仕組みとして設計されたトランスポートプロ トコルです。」 IETF で標準化している QUIC は、「Quick UDP Internet Connectio

Mew.org is now speaking HTTP/3 (HTTP/2 over QUIC). If you gain access to the site using Firefox Nightly, the first connection would be HTTP/2 then the following connections should be HTTP/3 led by Alt-Svc:. Firefox Nightly This article explains insights which I found through the implementation activities of QUIC and HTTP/3 in Haskell. HTTP/2 server library I started implementing QUIC in January 20

After implementing HTTP/2 in Haskell and TLS 1.3 in Haskell, I have been working for IETF QUIC. This article explains what I have done in 2019 fiscal year of Japan to report our sponsor, Internet Initiative Japan (IIJ). I have both titles of IIJ and IIJ-II. I'm wearing an IIJ-II hat in this article. If you wonder why I'm using Haskell to implement network protocols, please give a look at my positi

Closing connections gracefully is an old and new problem in network programming. In the HTTP/1.1 days, this did not get attention since HTTP/1.1 is a synchronous protocol. However, as Niklas Hambüchen concretely and completely explained, HTTP/2 servers should close connections gracefully. This is because HTTP/2 is an asynchronous protocol. Unfortunately, most HTTP/2 server implementations do not c

適宜更新します。 実用的でない例題 「他の言語だと雑多になるけど、Haskellではこんなに優雅なコードになる」という例は大抵実用的ではありません。本書では、以下の例題がそれに当てはまります。 1.5.2節のクイックソート (qsort) 6.4節のフィボナッチ数列 (fib) 15.6節のエラトステネスのふるい (primes) 実用的なコードを知りたいなら「Haskellの神話」を読んでください。 紹介されてないデータ型 実用的なプログラムを書く際には String ではなく Text を使います。textパッケージの Data.Text モジュールで定義されています。Text はリストではありませんので、リストプログラミングでは扱えません。専用の API を使って操作します。 非負の整数を表すデータ型は Word です。Data.Wordモジュールで定義されています。8.3節の例は、

プログラミングHaskell第2版の翻訳とレビューが完了し、ラムダノートから発売されました。レビューしてくださった5名の方に、改めてお礼を申し上げたいと思います。閉じられたissueは177個ですが、複数の指摘を含むissueもあるので、大雑把に言って250箇所ぐらいは改善されたのだと思います。 初版を買ってない方や、これからHaskellに入門したい人には、手放しでお勧めできます。この記事では、初版を持っているけど、第2版を買うべきか迷っている人に、どこが変わったのか説明します。 書体 コードが数学風の書体から、ブロック体になりました。Haskellに関する論文は、数学風の書体を使う伝統があって初版で採用されていましたが、これが一番不評でした。第2版では、奇を衒らわずに普通になりましたので、安心して読めると思います。 利用するシステム 利用するシステムが、HugsからGHCになりました。

I'm trying to develop QUIC in Haskell. In short, QUIC is a fast and reliable transport protocol based on UDP. You can think of it as TCP2. HTTP/2 over QUIC is now called HTTP/3. Two level dispatchings are necessary for QUIC: Dispatching QUIC packets to connections Dispatching QUIC streams in a connection to something (perhaps to lightweight thread workers) OS kernels are taking care of the first d

Haskell TLS library version 1.4.1 or earlier support SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1 and TLS 1.2. Here is brief summary of their security: SSL 2.0 is insecure and obsoleted by RFC 6176 SSL 3.0 is insecure and obsoleted by RFC 7568 TLS 1.0 is insecure due to lack of AEAD TLS 1.1 is insecure due to lack of AEAD TLS 1.2 is secure if it is used with proper parameters (using (EC)DHE and AEAD, disabl

Monadとは、Applicativeであるデータ構造で、(>>=)演算子を提供し、それがMonad法則を満たすものである。 正確に表現するとこうなんですが、「はぁ？」っ感じですよね。「満たすべき法則」とか言われると、まったく理解できません。でも、オススメの形に持っていくための変換規則と捉えると分かりやすいのではないかというのが、この記事の主旨です。 関手 関手法則は以下の2つです： 単位元： id <$> x = x 合成　： f <$> (g <$> x) = (f . g) <$> x 左辺が冗長な形、右辺がオススメの形です。これはいいですよね？ Applicative Applicative法則は以下の4つです（<*>は左結合）。 単位元： pure id <*> x = x 準同型： pure g <*> pure x = pure (g x) 交換　： x <*> pure y

Haskellがとっつきにくい原因の一つに遅延評価がある。入門書では、無限リストと遅延評価がことさら強調される。しかし、Haskellを業務で使ってみると、遅延評価が煩わしくなってくる。遅延評価なしでもほとんどのことは実現できるし、メモリーの使用量は推測できないし、あまりいいことはない。 Haskellの評価戦略が、他の言語と同じように正格評価だったらよかったのに。 今まで、このようなセリフを何度聞いたか分からない。 そもそも遅延評価が役立つことはあるのだろうか？ ある。お世辞抜きに、少なくとも以下の3つでは本当に役立つ。 リスト(あるいは類似のデータ構造)処理 純粋性に対する暗黙のテスト 効率的なCAS 1.はよいだろう。2.は純粋さを守るために必要だが、コンパイラを開発する人にとって重要なのであり、ユーザには関係ない。3.は、並行プログラミングの奥義である。atomicModifyIO

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

復習 Semigroup 結合則 (a・b)・c = a・(b・c) class Semigroup a where (<>) :: a -> a -> a Monoid 結合則 (a・b)・c = a・(b・c) 単位元 e・a = a・e = a class Semigroup a => Monoid a where mempty :: a mappend :: a -> a -> a mappend = (<>) 本題 Haskellerの中には、「設定はMonoidであるべき」宗派が存在する。そのような信念を持つHaskellerが作ったライブラリを使おうとすると、Monoid のインスタンスを (<>) でつないで設定データを構築することになる。 この記事では、SemigroupをMonoidに昇格させるのはいつかという話題を扱うので、まずSemigroupである設定データから始

はてなダイアリーからはてなブログに移行しました。今後も、細々とブログを書いていきます。 2018年8月、TLS 1.3がRFC8446になりました！(TLSのRFCは、伝統的にXX46という番号になります。) RFC8446の貢献者リストに僕の名前が載っていることを聞きつけたIIJ広報から依頼されたので、TLS 1.3の標準化と実装というブログ記事を書きました。執筆中にはリリースされていませんでしたが、現在ではTLS 1.3 対応済みの Firefox 63 と Chrome 70 が、めでたくリリースされています。 RFC8446の策定後、Haskell の tls ライブラリも、他の実装と相互接続性を確認しました。また、私の実装がtls ライブラリの本家にマージされました。Haskell tls ライブラリをリリースするには、 鍵のアップデート ダウングレード対策 クライアント認証 を

自分で定義するデータの中には、足し算したくなるようなデータがある。たとえば、送信と受信のカウンターを定義したとしよう。 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

kazuho さんが実装を進めている picotls を使う方法のまとめ。picotls は TLS 1.3 のみを実装している。またデフォルトで利用できる ECDHE は P256 のみである。 インストール cmakeが必要なので、あらかじめインストールしておく。master ブランチが draft 23。 % git clone https://github.com/h2o/picotls % cd picotls % git submodule init % git submodule update % cmake . % makeこれで、トップディレクトリに "cli" というコマンドができる。"cli" は、サーバにもクライアントにもなる。 picotls サーバ % ./cli -k $SOMEWHERE/key.pem -c $SOMEWHERE/certificate.p

これは「Haskell (その2) Advent Calendar 2017」の1日目の記事です。遅くなってすいません。 読者として末尾再帰ぐらいは理解しているHaskellerを想定しています。 トップレベルとローカル関数 再帰を用いて関数を書いているとき、トップレベルで再帰するか、ローカル関数で再帰するか、ときどき迷う。この記事では、僕なりの判断基準を示したい。 Data.Listで定義されている再帰が必要な関数は、ほとんどがトップレベルで再帰している。代表例のmapの例を見てみよう。 map :: (a -> b) -> [a] -> [b] map _ [] = [] map f (x:xs) = f x : map f xs mapをローカル関数を使う実装にしてみよう。この記事では、ローカル関数名としてgoを用いる。(loopを使う流儀もある。) map' :: (a -> b)

P256とかX25519とかPSSとか聞いても、よくわからない人のための用語解説。 長い間TLSの世界では、鍵交換にも認証にもRSAが使われてきた。必要となる安全性が大きくなると、RSAの公開鍵は急激に大きくなり、したがって鍵交換や認証のコストが大きくなるという問題がある。 楕円曲線暗号(ECC: Elliptic Curve Cryptography)は、RSAやDiffie Hellmanに比べると、小さな公開鍵で同程度の安全性を実現するという特長を持つ。特許問題が不透明なせいで楕円曲線暗号は長年敬遠されてきたが、この数年で(少なくとも鍵交換に対しては)一気に普及してきた感じだ。 おおざっぱに言うと、楕円曲線暗号で実現できるのは、DH(Diffie Hellman)とDSA(Digital Signature Algorithm)であり、RSAは実現できない。 鍵交換のDHに関しては、

PatternSynonymsは、その名の通り、パターンの別名である。GHC 7.8.1 で導入された。GHC 7系のPatternSynonymsは、モジュール内に閉じて入れば何の問題もなかったが、モジュールの外へexportする際は、patternキーワードが必要であり、構成子らしくなかった。 {-# LANGUAGE PatternSynonyms #-} module A (Foo, pattern Zero) where newtype Foo = Foo Int pattern Zero :: Foo pattern Zero = Foo 0 GHC 8 からは、patternキーワードが不要となり、構成子らしくなった。 {-# LANGUAGE PatternSynonyms #-} module A (Foo(Zero)) where newtype Foo = Foo I

何度読んでもよく分からないDNS関連のRFCを自分なりに読みやすいようにまとめる私的メモ。 ちなみに、僕は Haskell DNS ライブラリの作者で今も精力的に開発中。 RFC 1035 RFC 1035で定められている構造をトップダウン的に列挙する： メッセージ全体 +---------------------+ | Header | +---------------------+ | Question | the question for the name server +---------------------+ | Answer | RRs answering the question +---------------------+ | Authority | RRs pointing toward an authority +---------------------+ |

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

経緯 Chrome は version 56 から TLS 1.3 ID 18 をサポート(0-RTT 以外)。 Chrome 56 の前にBlueCoatがある状態で Google サービスにアクセスしようとすると、アクセスできないことが判明。 ChromeはTLS.13をdisabledに戻した。 原因 TLS 1.3は、TLS 1.2と区別のつかないClient Helloを送る。拡張でバージョンが1.3だと教える。 TLSの実装は、知らない拡張は単に無視してエラーにしてはいけないという鉄則により、TLSのバージョンアップは順調にいくはずだと信じられていた。 BlueCoatは、サーバからのCertificateの中身を見て、中継するか否かを決めるらしい。 TLS 1.3を知らないBlueCoatには、Client HelloがTLS 1.2に見える。 しかし、サーバから戻って来たハ