今月の"今なにやってんの"

nmosh

先月からは半月強しか経ってないのであんまり進捗が。。今月からはもうちょっとこまめに記録して、この欄はスピーディーに書けるようにしたい。
teslawireは進捗なし。。ちょっと方針を考えないと不味いかもしれない。yuniは"やりたいことから進める"でそれなりに進捗しているので、同じ方針が良いのかも。

nmosh Scheme と yuni

nmosh SchemeはR6RS/R7RS Scheme環境。常識的な速度で動作するのと、それなりに使いやすいフロントエンドやアプリケーション組込みサポート(Win32上のnmoshのみ)がウリ。現在は主に次期バージョン0.2.8で最大の機能追加であるyuniの実装中。
yuniはR6RS/R7RS Scheme用の移植性ライブラリで、Racket / Gauche / Chibi-Scheme / Larceny / Sagittarius / Guile / Vicareでnmoshと同じアプリケーションを実行できるように共通のライブラリ基盤を実装しようというもの。Scheme処理系で共通して使用できるFFIフレームワークyuniFFIが中心的なライブラリ。yuniFFIはS式を使用したC API記述フォーマットStubIRを基盤とした静的FFIで、ギリギリまで切り詰めたネイティブインターフェースで処理系固有の要素を最小化している。
先月は、

R6RS互換ライブラリは、あまり急ぐことはないなという印象。FFIランタイムの実装のために必要であれば先にやるけど、既存のアプリケーションの0.2.8移行が可能であることがわかってからでも遅くはないということで。
今月は、

の2点を行っていく。
StubIRトランスレータは、StubIRで記述されたAPI情報をSchemeとCの各ソースコードに変換する。Cへの変換はStubIRのS式とほぼ一対一対応で出力できるようにCマクロを準備している。なので、Schemeライブラリの出力が重要なトピックになる。Schemeライブラリを出力するには、まず、FFIランタイムの仕様を確定させておく必要がある。
FFIランタイムはC APIを自然なScheme手続きに見せるために多くの機能を必要とする:

  1. パラメータパケットの生成
  2. 構造体の構築とアクセス
  3. 引数の補完とバリデーション
  4. 数値のシンボル化とシンボルの数値化

StubIRとこれから生成されるSchemeライブラリは、これらの動作に必要な"データ"だけを基本的には提供する。しかし、常識的なパフォーマンスを実現するには、単にデータを提供するだけではなくマクロによる事前展開で手続きを構築してしまう必要があるかもしれない。
これらの4要素の検討から作業を始めていく。