週刊nmosh - nmoshの今年と来年

率直に申し上げて今年は本当に何も出来なかった。やっぱりロンチだ何だとやっているとサッパリ身動きが。。
今年は、PreciseGC化やSub-VMのような既存コードベースの直線的な進化にフォーカスして色々と試してみて、それらが全て上手く行かなかった。ヒープシステムをそのままにしてVMを差し替えたRubyYARVと逆の方向性の努力なので、なかなかうまく行きづらいというのは想定通りなのだけれど。
R7RSは今のところ個人的にあまり需要が強くないのでちゃんと纏められていない。ただ、フロントエンドとしてちゃんと構成することの必要性は理解出来たので良しとしたい。。
マルチスレッドAPIVM APIは実装して、実際便利に使っている。ただ、Win32以外で実装されていないので通常のユーザにはほぼ役に立たない。。

来年

来年は:

  • ドキュメント!!

なんか毎年出ているのに手がつかない。。今年はドキュメント構成の選定をして、DITAで行くことに決めた。個人的なプロジェクトではGNU texinfo/DocBookを採用して来たけれど、最近の商用ソフト/ライブラリでDITA様式のドキュメントが多くて、フリーフォーマットの文書で提供するよりも参入障壁が低そうということで。ただ、最大の理由はコストカットと言える。
DITAは(平たくいえば)ドキュメントを京大式カードで書くことを要求するようなもの。つまり、1要素1トピックであり、(必要なら)外部に記述したDITA mapによって章構成を行う。トピックは他のトピックから独立/完結し、差し替え可能であることが想定されている。
個人的には最初から順番に読んでいくようなドキュメントに慣れ親しんでいるので、このような形式が本当に良いのかは何とも言えないポイント。つまり、先頭から読める(読みやすい)ドキュメントにコストを掛ける価値が有るかという問題が在って、書かなきゃいけない分量も多いし、翻訳も必要なのでそのコストを考えると見合わないのかな。と。どうせin-lineなREPL上のドキュメントも必要で、それも一緒にできる。
XMLを直接書くかmarkdown拡張を経由するかは考え中。というか、DITAをどう書いてコンバートして公開するかみたいな調査自体からこれから始める。

  • yuni: 基盤ライブラリのポータビリティ

現状のvanilla VMを拡張していく方向性はどうやっても上手く行かなかったので、長期的にはライブラリレベル互換実装を用意する方向性になる。基盤になるライブラリのポータビリティを確保することで、他の実装を調査して将来のVMデザインを良くしましょう活動。
具体的には、非同期構文とイベントキュー(async)、pFFI(現状はnmosh側にある)、簡易オブジェクトシステム(core)をR6RS/R7RSポータブルに用意し、手元のコードは他のScheme処理系でも動かせる状況にする。
現状のr7rs-bridge形式(define-libraryの替りにlibraryを使い、body先頭にbeginを入れてR6RS/R7RS処理系の両方で読めるようにしたライブラリ)は止めて、素直にR6RS形式の基幹ライブラリをincludeしてくる形式に変更する。というは、既存のR7RS処理系は全てライブラリにexpandするマクロをサポートしているので、特段R7RSのライブラリ構文に合わせる需要が無いため。 ...ついでに、同じ方式を使えばRacketで#!r6rsが要らなくならないかな。。あとで試す。
R6RS記述のライブラリを直接変換してR7RS形式のライブラリにしないのは、エラー行等のライブラリ自体の構文情報が保持されるのを期待して。coverageのような情報が取れる処理系が有れば、それが保持されるのも期待している。

  • UCID: Cインターフェース記述(Unified C Interface Description)と移植可能な擬似FFI(pFFI)

Cインターフェース記述フォーマットの確立は非常に重要な問題になって来たので多分来年最大のトピックになる。
平たく言えば、C言語API仕様をS式で書いてFFIバインディングを生成させたい。もっともUCIDを手書きすることにはあまり大きな関心は無くて、これを良く定義することによって、C言語ASTやDWARFから生成することが主眼にある。
UCIDの目的はGCフレンドリなバインディングを生成する点には無い。常識的なライブラリはどうせreference countingを持っているので、そちらと統合するインターフェースを用意するほうがずっと良いだろう。Schemeからsyscallが呼べれば十分で、多くの場合は構造体をトラバースする必要もない。
UCIDはその主目的であるFFIバインディングの生成よりも、API呼び出し解析ツールのようなinspection/reflection用途の方が(世間的には)重要になるだろう。ただ、処理系にとって重要なのは、OSインターフェースを全てUCIDを通して操作することで、上位のライブラリと下位のVMの独立性を高めることが出来る点に有る(= 上位のライブラリはUCID処理系が対応する任意のScheme処理系で動かせるはず)。
この領域に関してUCID自体が標準になることを狙うというよりは、この手のreflection方法論は絶対に今後流行るので"その時"に備える意味合いが大きい。その時点で流行しているものをUCIDに変換するトランスレータを用意すれば良い。そういう将来像があるので、Scheme固有の機能はUCIDに盛り込まれない。