LunarMLの今年の進捗を振り返ります。この記事は言語実装 – Qiita Advent Calendar 2024の14日目の記事です。
続きを読む「Standard ML」カテゴリーアーカイブ
LunarMLと文字列フォーマット
LunarMLをLuaの代替として使う際、Luaの機能を自然に使えると良さそうです。例えば、文字列フォーマット関数 string.format を呼び出す際には現状では引数の型キャストが必要ですが、フォーマット文字列にいい感じの型をつければキャストが不要になるのではないでしょうか。
ML系言語の仲間であるOCamlには、フォーマット文字列が期待される文脈で特別な型付けを行う機能があります。LunarMLでも似たようなことをするといいのではないか、というわけで検討します（検討するだけならタダなので）。
続きを読むClutTeXとLunarMLの近況
本の諸々が一段落したので、最近はLaTeX処理自動化ツールClutTeXの開発を進めています。前（2023年11月）に計画を書いて以降の進捗を書きます。
続きを読むLunarML/Standard MLのブートストラップ問題
LunarMLを含む多くのStandard MLコンパイラーはStandard ML自身で記述されています。すでに動くStandard ML処理系があればSMLで書かれたコンパイラーを動かせますが、Standard ML処理系のない新しいプラットフォームでStandard MLコンパイラーを動かしたい場合はどうすればいいでしょうか？
続きを読むLunarML v0.2.0リリースと最近の進捗
LuaやJavaScriptを出力するStandard MLコンパイラー「LunarML」のバージョン0.2.0をリリースしました。
続きを読むプログラミングではたまにエスパー力が必要になることがある
西暦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年に先送りしたに過ぎません。
そして、時刻の表現を「秒単位」ではなくもっと細かい単位にするとこの限界はもっと早くやってきます。この記事では、時刻の表現をどういう刻みで何ビットにすると限界がいつになるのかを検討してみます。
続きを読むStandard MLのIOとLunarMLのIO
プログラムにとって入出力は大事です。入出力機構がないと、計算の入力を受け取ることも、出力を出すこともできません。
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択を持てるようにする案です。ストリームからプリミティブ入出力のインターフェースを得る場合は、ファイル記述子っぽいものを含めて、逆の操作（ストリーム入出力の構築）を行うときに「スクリプト言語の提供するストリーム」を復元できるようにします。ファイル記述子としては、スクリプト言語の提供するストリームと独自に割り当てる整数をハッシュテーブルで対応させて管理することにします。
まあ、言葉にするのは簡単ですが（これでも結構考えたのですが）、実装するのは面倒くさいです。少しずつやっていきます。
TOMLパーサーを書いた／設定ファイルについて思うこと
TOMLについて
プログラムの設定ファイル、あるいはプロジェクトファイルとしては、さまざまなファイル形式が使われてきました。古くはINI、近年はJSONやYAMLなどです。最近よく見かけるのがTOMLです。Rustの Cargo.toml やPythonの pyproject.toml などで使われています。仕様は
で参照できます。TOMLはTom’s Obvious, Minimal Languageの略ということになっており、ミニマルでわかりやすいことがウリのようです。
私がStandard MLで書くプログラムの設定ファイルにもTOMLを採用するかもしれません。しかし、Standard ML向けの既存のTOMLパーサーはまだなさそうです。なので、実装してみました。
続きを読むLunarMLの構文をイケイケにするために
Standard MLとLunarMLの関係について、前にこういう記事を書きました。
この時は割と互換性重視でしたが、しかし、クソリプおじさんからの批判に耐えるにはもう少し抜本的な改革が必要そうです。非互換性を厭わずに構文を変えるならどういう構文にしたら良いでしょうか。
（まあクソリプおじさんが前の記事を読んでいたかは定かではないのですが。人が百も承知なことに対して上から目線でご高説を垂れるからクソリプなのです。釈迦に説法という言葉もありますね。）
続きを読む