「Standard ML」カテゴリーアーカイブ

良いコンパイラーは親切なエラーメッセージを出さなければならない：LunarMLの場合

プログラミング言語の静的解析の良い点として、一回の解析で複数の誤りを検出できる（場合がある）点があります。実行時エラーしか出ない言語だったら、一回の実行で一個のエラーに遭遇して、修正して、またエラーに遭遇して、ということを繰り返さなければなりません。

言い換えると、遭遇した最初の誤りでコンパイルが停止してしまうようなコンパイラーは、いくら静的な型システムを備えていても、動的言語並みの貧弱な開発体験しか得られないということです。コンパイルの手間がかかる分むしろマイナスです。

コンパイラーではなく言語サーバーでも同じことで、ソースコードの最初の誤りで解析が停止してしまう言語サーバーからは貧弱な開発体験しか得られないでしょう。

検出できるエラーの個数だけではなく、エラーメッセージの親切さも、結構開発体験を左右するのではないかと思います。よくある誤りに対して的確なエラーメッセージを出すことができれば、ユーザーがエラーの原因で悩む手間が省けます。

一つの言語仕様に対して複数のコンパイラーが存在する状況で、エラーメッセージの品質はコンパイラー間での差別化の要素になり得ます。この記事では、Standard MLコードに対して良いエラーメッセージを出す工夫について考えてみます。

続きを読む →

LunarMLとJavaScriptの連携について

久しぶりにLunarMLの話題です。LunarMLは、私が作っているStandard MLコンパイラーです。

最近は、JavaScriptとの連携に関する機能を追加しています。Webで使えるようにするのと、Promise/async/await周りの統合をいい感じにすることを目標にしています。

続きを読む →

never型があると便利か（言語処理系実装者の観点から）

TypeScriptをはじめとするいくつかのプログラミング言語には、never型という型がある。この型は典型的には「制御を返さない関数」の返り値として使われる：

function f(x: string): never {
    console.error(x);
    throw new Error();
}

never型は型システム的には「値を持たない型」「任意の型の部分型」として特徴づけられる。

他のプログラミング言語、例えば私が作っているLunarMLにもnever型があると便利だろうか？

続きを読む →

LunarMLと文字列フォーマット

LunarMLをLuaの代替として使う際、Luaの機能を自然に使えると良さそうです。例えば、文字列フォーマット関数 string.format を呼び出す際には現状では引数の型キャストが必要ですが、フォーマット文字列にいい感じの型をつければキャストが不要になるのではないでしょうか。

ML系言語の仲間であるOCamlには、フォーマット文字列が期待される文脈で特別な型付けを行う機能があります。LunarMLでも似たようなことをするといいのではないか、というわけで検討します（検討するだけならタダなので）。

続きを読む →

LunarML/Standard MLのブートストラップ問題

LunarMLを含む多くのStandard MLコンパイラーはStandard ML自身で記述されています。すでに動くStandard ML処理系があればSMLで書かれたコンパイラーを動かせますが、Standard ML処理系のない新しいプラットフォームでStandard MLコンパイラーを動かしたい場合はどうすればいいでしょうか？

続きを読む →

プログラミングではたまにエスパー力が必要になることがある

プログラミングをやっていると、たまにエスパー力が必要になることがあります。つまり、不可解な現象に遭遇し、少ない手がかりで問題を解決しなければならない状況です。

私はLunarMLという言語処理系を趣味で作っているのですが、今回はそれの開発中に遭遇した出来事を取り上げます。

続きを読む →

西暦2262年問題に対処するべきか

西暦2038年問題はみなさんご存知ですよね。2038年1月19日午前3時14分7秒（UTC）を過ぎると 世界中のUNIXがばくはつする問題 time_t が符号付き32ビットなプログラムで現在時刻を正しく扱えなくなる問題です。

C言語の time_t は典型的にはUnix epoch（UTCで1970年1月1日午前0時）からの経過時間（うるう秒は考慮しない）を秒単位で保持しており、それが\(2^{31}-1\)に到達するのが2038年1月19日午前3時14分7秒（UTC）なわけですね。

2038年は割と近い将来なので、モダンなC処理系では time_t を64ビット整数にするなどの対応を行なって2038年問題を乗り切ろうとしています。

それでも、時刻を固定長整数で表現する限り、いつか限界が来ます。「time_t を64ビット整数にする」という対応は、問題を西暦2038年から西暦292277026596年に先送りしたに過ぎません。

そして、時刻の表現を「秒単位」ではなくもっと細かい単位にするとこの限界はもっと早くやってきます。この記事では、時刻の表現をどういう刻みで何ビットにすると限界がいつになるのかを検討してみます。

続きを読む →