週刊nmosh - 0.2.8計画
長いことやってるのかやってないのか微妙な状況でしたが、ロードマップを作った上で0.2.8は年末を目標に。基本的にteslawire(個人的に制作中のゲーム)のシナリオや他の仕事が有るのであんまし時間は掛けられないですが。。
あと今回から可能な限りちゃんと週刊にしようと思います。。今週やること / 先週やったこと だけでも。
nmoshの目標
どちらかと言うと遠い未来に向けて。
- 良いshell / C APIのブレッドボード
psyntax-moshと共有する目標として、暮せるREPLを目指します。カレントディレクトリを一つもって、UNIXコマンドと1対1対応というスタイルでは無くなるかもしれませんが。
例えば、動作中のプログラムに入っていくとか、API呼び出しストリームをteeするとか従来のshellを越えた機能性をshellくらい気軽に使えるように。
shellの良い面は、コマンドを組み合わせてブレッドボード的に活用できるところで、それをC APIのレベルに拡張したい。
- "リーズナブルな"速度
Schemeは宇宙最速を目指すには向いていないので"リーズナブルな"くらいで。起動時に触るファイルが少いとか、余計な機能を初期化しないとか。
- 浸透性
動的言語を褒めるときによく"柔軟性が高い"という言い回しが使われますが、nmoshは一歩進めて浸透性を目標にします。
S式抽象が便利なところが有れば、nmoshを組み込んでもらって後はnmoshの存在自体は忘れられるように。nmoshはC構造体やC API呼び出し、パケット等バイナリデータとS式の相互変換とScheme的なS式操作手続きを提供するので、後はSchemeの世界でコミュニケートすればOKというレベル。
- 良いフロントエンド
良いフロントエンドはこれからのプログラミング言語の必須要件になると思います。Swiftがplaygroundを作れるのも良いフロントエンドが存在するからで、構文エラー時に"syntax error"としか言わない言語フロントエンドは多分時代遅れ。
エラーメッセージのローカライズやcode completion、edit and continueができるレベルのAPIを提供するべき。
0.2.8 でやること
ドラスティックな拡張は0.2.8では入れない方針。
- R7RS 形式ライブラリのサポート
R7RS ライブラリのimportとライブラリをサポートします(nmoshのみ)。現状のokuoku/masterで既に利用可能。ReaderはSchemeで書いた専用のものを別途用意する方向。
バイトコードコンパイルキャッシュとも統合されているので、includeしたファイルはちゃんと依存に入ります。
もっとも、ネイティブreaderも殆どのR7RS構文はサポート。ただし長いシンボル構文のみ非サポート(非互換になるので)。
- R7RS smallライブラリのサポート
psyntax-moshとnmoshの両方で、(import (scheme base))のようにすればR7RS small相当のライブラリを利用できるように。
これもokuoku/masterで既に利用可能。但しmap等は依然等長を要求する。
- 日/英の.chm形式ドキュメント
DITAを粛々と。。会社ではoXygen + TRADOSというワークフローだけど流石にそれを揃える予算が無いので、Markdown(テキスト形式)のコンバータを用意してomegaTでどうにかするつもり。章立て構成等はまだ検討中。UNIX/Macでは良いフォーマットが無いのでどうしたものか。。
ドキュメントに関してはリポジトリを分割する予定。翻訳の品質を保つために大量のメタデータをコミットすることになるので。
yuniFFIはC API記述からバインディングを生成するFFIフレームワークで、従来の動的バインディングなFFIを補完するもの。yuniライブラリはGaucheとRacket向けにも制作するので、1つのアプリケーションを3つのSchemeで動かしてnmoshのチューニングに役立てるつもり。
0.2.8ではAPIが呼べるだけ。nmoshのOS依存部は今後全てyuniFFIで記述する。Win32は現状のnmosh程度のバインディングのみ提供。POSIX2008は最初から殆どの関数が呼べるようにしておきたい。。Linux/Mach/BSDの重要なパフォーマンスプリミティブ(kqueueとか)も呼べるようにしたい。
- psyntax-mosh / nmosh片方のみのインストールサポート
psyntax-moshがMobile shellの方と被って使用できない環境が多いのでインストールを無効にできるように。同様に、nmoshの方を使わない人も多そうなのでnmoshも無効にできるように。
- "ホスト" BoehmGCのサポート
いくつかのLinux(というかFedoraとDebian)はライブラリの重複収録をポリシとして許容していないので、BoehmGCをホストの共有ライブラリから使用できるように。ちなみに、Cygwin64もこれが必要(バンドルBoehmGCがサポートしていないため)。
ホストBoehmGCはこちらからconfigを強制できないので、pairサイズの最適化等いくつかの最適化は無効になる。
これもokuoku/masterでは既に使用可能。
- (nmosh)、(yuni)ライブラリの廃止
現状のnmoshライブラリは全部廃止され、yuniFFIで記述されるyuniライブラリに置き換えられる。wxWidgets等はスピンアウトさせる予定(yuniFFI同様これらもScheme処理系間でポータブルにできるので)。
0.2.9 でやること
0.2.9はteslawireと平行して設計中。いくつかゲーム向けのドラスティックな拡張を入れる。時期はteslawireと一緒、なのでまだ秘密。
- mini-nmosh
C言語1ソースのみで記述される、nmoshと言語レベルで互換の小さなVM。正確なGCとマルチスレッドのサポート。
mini-nmoshが将来のnmosh本家になるかどうかは未定。パフォーマンス的に優れない限りは置き換えないつもり。0.2.9でのmini-nmoshは現状のnmoshの1/2から1/5くらいの速度(= chibi-scheme同等)で動作するのがターゲット。基本的にはbaremetalで動作するレベルのポータビリティを先に目指す。
teslawireの動作環境であるemscriptenのサポートがプライマリな目標。
- yuniFFI デバッガAPI
yuniFFIのAPI呼び出しをS式で受け取り、ブレークしたり結果をinterceptしたりといったデバッガAPI。SchemeコードからのAPI呼び出しというよりは、これをネイティブコードに適用させるのが最終的な目標。これができないとJITしたコードのデバッグができない。。ただしScheme側のJITは0.2.9でもやる予定は無い。
yuniFFIのAPI呼び出し専用のVM。API呼び出しだけ高速にできてもあまり意味が無いので、DSP的な演算とバッファ操作も。要するにソフトウェアスキニングが必要な時にこれを使ってモデルの変形を実装し、直接GLのAPIで(Scheme側を経由せず)頂点を転送する。ここまでしないとアクションゲームは無理。。
DSP的な処理はPCでもキツいため、yuniFFI VMは最初からCトランスレータを想定する。これに関してはlibclangとかlibtccでJITCも検討したい。
技術的に面白そうなポイントは、原理的にはyuniFFI VMでmini-nmoshを代替できる点。いまのところ両者の差を埋める良いアイデアが無いが、pypyにおけるRPythonのように、Schemeの制限付きサブセットで必要な機能性とトランスレータを表現できれば、記述しなければならないCコードを最小化できる。
