西暦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年に先送りしたに過ぎません。

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

プログラムにとって入出力は大事です。入出力機構がないと、計算の入力を受け取ることも、出力を出すこともできません。

Standard MLにも当然入出力に使う型と関数が定められています。例えば、print 関数は標準出力に文字列を出力し、flushします。TextIO や BinIO などのモジュールを使うと、ファイルの読み書きを行うこともできます。

LunarMLも、これらのモジュールを一部実装しています。しかし、今の実装はやっつけなので、もっとしっかりした（準拠度の高い）実装にしたいです。

Standard MLの入出力

Standard MLの入出力はいくつかのレイヤーに分かれています。

一番高いレイヤーが「手続き的入出力」すなわち IMPERATIVE_IO や TEXT_IO や BinIO です。これらは

• 手続き的な入力
• 手続き的な出力
• ストリームのリダイレクト

などの機能を提供します。

手続き的入出力は、ストリーム入出力のラッパーと思えます。手続き的入出力のストリームの型はストリーム入出力の型を使うと

type instream = StreamIO.instream ref
type outstream = StreamIO.outstream ref

という風に理解できるでしょう。

ストリーム入出力は STREAM_IO で表されます。機能的には、

• 関数的な（遅延リスト的な）入力
• 手続き的な出力
• バッファリング

を提供します。「関数的な入力」というのは、例えば「一文字読み取る」関数が

val input1 : instream -> (elem * instream) option

という型を持ち、「入力に与えられたストリーム」とは別の「一文字読み取った後のストリーム」を返すということです。同じストリームに input1 を複数回適用すると同じ結果が得られることが期待されます。

ストリーム入出力の下にあるのがプリミティブ入出力です。プリミティブ入出力 PRIM_IO は、システムコールを抽象化したものだと思えます。機能的には、

• バッファリングなしの、手続的な入出力
• ノンブロッキングIO（オプション）
• ランダムアクセス（オプション）
• OSのファイル記述子へのアクセス（オプション）
  • ファイル記述子に対しては、等価性比較、ハッシュ値の取得、大小比較ができることが想定されています。

があります。ただし、プリミティブ入出力はあくまでインターフェースを定めるものであり、特定のシステムコールに紐づいたものではありません。特定のシステムコールを呼び出すプリミティブ入出力の実装を提供するのは openIn とか stdIn とかを提供する側の役目です。

Standard MLにはこのほかに、OSのシステムコールに対応する型と関数が規定されています。

LunarMLの入出力

LunarMLは、スクリプト言語の提供する入出力機能をラップしてStandard MLの型と関数として見せたいです。スクリプト言語の提供する入出力機能とは、Luaで言えば io モジュール、Node.jsで言えば Readable/Writable などのストリームです。

スクリプト言語の提供する入出力機能をシステムコールとみなしてプリミティブ入出力として提供できれば良かったのですが、現実にはそううまくはいきません。スクリプト言語の提供する入出力機能にはバッファリングがあるのに対して、プリミティブ入出力にはバッファリングはありません。具体的には出力ストリームのflush操作がプリミティブ入出力にはないのです。書き込み操作の度にflushすればエミュレートできるかもしれませんが、ストリーム入出力のレイヤーでバッファリングを再実装するのかという問題もあります。

今考えているプランは、ストリーム入出力を単なるプリミティブ入出力のラッパーとするのではなく、内部実装として「プリミティブ入出力、あるいはスクリプト言語の提供する（バッファリングされた）ストリーム」の2択を持てるようにする案です。ストリームからプリミティブ入出力のインターフェースを得る場合は、ファイル記述子っぽいものを含めて、逆の操作（ストリーム入出力の構築）を行うときに「スクリプト言語の提供するストリーム」を復元できるようにします。ファイル記述子としては、スクリプト言語の提供するストリームと独自に割り当てる整数をハッシュテーブルで対応させて管理することにします。

まあ、言葉にするのは簡単ですが（これでも結構考えたのですが）、実装するのは面倒くさいです。少しずつやっていきます。

Standard MLとLunarMLの関係について、前にこういう記事を書きました。

この時は割と互換性重視でしたが、しかし、クソリプおじさんからの批判に耐えるにはもう少し抜本的な改革が必要そうです。非互換性を厭わずに構文を変えるならどういう構文にしたら良いでしょうか。

（まあクソリプおじさんが前の記事を読んでいたかは定かではないのですが。人が百も承知なことに対して上から目線でご高説を垂れるからクソリプなのです。釈迦に説法という言葉もありますね。）

LunarMLの今年の進捗を振り返ります。