この記事は Haskell Advent Calendar 2023 の6日目の記事です。 私はここ数年、HaskellコンパイラーであるGHCに貢献しています。この記事では、今年（2023年）に私が行った貢献を紹介します。 GHCの開発は独自ホストされたGitLab上で行われています。 Glasgow Haskell Compiler / GHC · GitLab 私の貢献 今年は貢献と言っても、バグ報告のみ（修正パッチは含まない）のケースが多いです。私はLunarMLが忙しいので……。 FMAについてコメント（2月ごろ） 2〜3月ごろに、FMA (fused multiply add) を計算するプリミティブをGHCに実装するマージリクエストが出ていました。 !9996: Add fused multiply-add operations · Merge requests · Glas

このブログでは限定継続について過去に何回か記事を書きました： LunarMLと継続限定継続と例外とモナド 今回、LunarML向けのVMに限定継続を実装してみて理解が深まったので、改めて記事にします。 限定継続：スタックを使ったざっくりとした説明 今回はスタックを使って限定継続をざっくりと説明してみます。 関数という概念を持つプログラミング言語では、スタックを使って関数の呼び出しを管理することが多いです。コールスタックとか、スタックのバックトレースとか言いますよね。ここではネイティブのスタックか仮想マシンのスタックかというのは問いません。 関数を呼び出すと、フレームと呼ばれる領域がスタックに確保されて、関数への引数やローカル変数はそこに確保されたりします。 例えば、以下のプログラムを考えます： void g() { // すごい計算 } void f() { double j; g();

前回の記事 AArch64アセンブリーを出力するBrainfuckコンパイラーを書いてみる ではBrainfuckコンパイラーを書きましたが、やはりレジスター割り付けもしないコンパイラーでは物足りないと思ったのでした。 コンパイラーを作るオンラインの教材として前回の記事ではMinCamlと「低レイヤを知りたい人のための〜」を挙げましたが、後者はレジスタ割り付けはやらないみたいなので、MinCamlをやっていくことにします。 単にAArch64対応させるだけなら元のMinCamlとの差分だけを書けば良いのですが、どうせなのでHaskellに移植します。 先に成果物を載せておくと、 minoki/min-caml-hs: MinCaml implementation in Haskell です。 作業記録は MinCaml写経日記 に書きましたが、この記事でも要点をまとめておきます。 MinC

最近、「Haskellでの型レベルプログラミング」という「本」を執筆している。まだ完成ではないが、以下のリンクから読める： Haskellでの型レベルプログラミング なぜHaskellか 最近いろんな言語が出てきている中で、Haskellの強みとは何だろうか。人によって答えは色々あるだろうが、筆者にとってHaskellの魅力的な側面は強力な型システムである。どのくらい強力かというと、型レベルでプログラミングができ、依存型の模倣さえもできてしまう。 （依存型をやりたいなら最初から依存型のある言語を使えという意見は尤もだが、それはそれとして。） Haskellでの型レベルプログラミングの解説記事というのは、英語圏ではちらほら見かけるが、日本語圏ではあまり見ない。2018年（原文は2017年）に公開された Haskellにおける型レベルプログラミングの基本(翻訳) – Qiita が数少ない例で

先日リリースされたGHC 9.2.1で、64ビットArm（AArch64）向けのネイティブコード生成器（Native Code Generator; NCG）が実装された。これを機会にGHCのバックエンドについて簡単にまとめてみる。 概略 GHCでHaskellプログラムをコンパイルすると、いくつかの中間言語を経て最終的には機械語が出力される。 この工程の最後の部分を「バックエンド」と呼ぶ。 GHCには Native Code Generator (-fasm)LLVM backend (-fllvm)unregisterised via-C backend の3種類のバックエンドが存在する。このほか、バイトコードインタープリターと-fno-codeもデータ型的にはバックエンドの一種として扱われている。（参照：compiler/GHC/Driver/Backend.hs） Native C

事実上の標準デファクトスタンダードなHaskell処理系であるGHCに貢献するというのが去年掲げた目標だったが、それがようやく実現したので報告する。ついでに、最近のGHC開発状況についても簡単にまとめてみる。 「貢献」と言っても色々あって、バグ報告とかも立派な貢献なのだが、ここで目標としていたのは「書いたコードをGHC本体に取り込んでもらう」ことである。 一つ目：fromInteger :: Integer -> {Float,Double} 年末に書いた記事 Haskell/GHCでの浮動小数点数の扱い – Qiita にあるように、現行のGHCのfromIntegerは値の大きさによって丸め方法が違っている。それによってどういう問題が引き起こされるかというと、 import Numeric import Data.Word main = do putStrLn $ "literal :

Haskellにおけるモノイドについて解説記事を書いてみた。他の言語でも通用する話があるかもしれないし、ないかもしれない。 モノイドとは モノイドとは、ざっくり言うと「くっつける」演算ができる対象のことである。例えば、文字列やリストの連結、数の足し算や掛け算は「くっつける」演算の一種である。 モノイドには「くっつける」演算の他にもう一つ条件があって、モノイドは「くっつけても何も起こらない値」を持っていなければならない。例えば、文字列の場合は空文字列、リストの場合は空リスト、数の足し算の場合は0、掛け算の場合は1、という具合である。 というわけで、文字列、リスト、数の足し算、数の掛け算はいずれもモノイドの具体例である。ただし、同じ数の集合（整数、など）を考えていても、演算が異なる（足し算 vs 掛け算）場合は、異なるモノイドとみなす。 モノイドの定義をちゃんと書くと、モノイドとは集合 \(M

Qiitaにこういう記事を書いた： Haskellでフィボナッチ数列 〜Haskellで非実用的なコードを書いて悦に入るのはやめろ〜 ↑の記事ではメモ化しない計算法が遅いこと、Haskellには遅延評価の罠があって正格にすると早くなること、「n番目のフィボナッチ数」をピンポイントで計算する場合は（行列またはQ(√5)の）冪乗を使う方法が早いこと、一般項（ビネの公式）をその辺の浮動小数点数で計算するのは使い物にならないこと、などを述べた。 まあ、「Haskellでは fib 0 = 0; fib 1 = 1; fib n = fib (n-1) + fib (n-2) でフィボナッチ数が計算できます！」に対する注意喚起としてはこれで十分すぎる内容なのだが、「n番目のフィボナッチ数をピンポイントで計算する方法」についてはもっと深掘りできる。 この記事では、数学的な考察も交えて、「n番目のフィボ

この記事は Category Theory Advent Calendar 2018 7日目 かつ Haskell (その2) Advent Calendar 2018 7日目の記事です。 Category Theory Advent Calendar 2018の6日目はcorollary2525さんの「随伴は　あらゆるところに　現れる」、8日目は空席、9日目はt_uemura669101さんの「トポスと高階論理」です。 Haskell (その2) Advent Calendar 2018の6日目は空席、8日目はtakoeight0821さんの「Type defaultingについての初級的な解説」です。 この記事はどういう記事か 圏論の方から来た人向け： デカルト積やテンソル積の一般化である「モノイド積」の話と、「内部ホム」の話をします。文献によっては内部ホムはモノイド積の右随伴として導

前置き TypeScript で作っていたプロジェクトに、後付けで PureScript を追加しようとしたらかなり辛かった。 （わざわざ言語を混在させたい理由としては、型クラスや演算子オーバーロードを使いたい＆既存のコードを全部書き直す暇はない、が挙げられる） 辛い理由としてはそもそもモジュールとバンドラーの周辺がまだ成熟していないというのもあるだろうが、 TypeScript 固有の理由として、 TypeScript コードから PureScript モジュールを読み込むための型定義が足りないという問題がある。 Stack Overflow を見ると、同じことで悩んでいる人がいた： node.js – How do I configure a TypeScript project that uses JavaScript modules compiled from PureScript

Haskell は表現力が高いプログラミング言語だが、気をつけないと非効率的なコードが生成されてしまうことがある。では、どういうところに気をつければ高速なコードになるのか。少し調べてみた。 この記事に書くのは、あくまで原則とかそういうやつなので、コンパイラーの最適化（正格性解析、インライン化、自動ボックス化解除）によっては、自前で工夫しても意味がない、つまり、コンパイラーに任せた場合と同じ結果になるかもしれない。どういう場合に早くなるかはケースバイケースなのだ。 ここで扱うトピックは大きく分けると、 正格評価 型クラスの特殊化 Unboxed 値 その他 となる。あくまで自分用の備忘録であり、特に突飛なことを書いているつもりはないので、知ってる人はアーハイハイという感じで読み飛ばしてしまえるだろう。また、筆者の理解が浅く、誤解に基づいたことを書いているかもしれないので、あまり信じすぎないよ