方針転換

DrSchemeと紛らわしいので、dryScheme→skySchemeと改名した。??ySchemeにしたくて*1、flySchemeとかcrySchemeとかいろいろ考えたけどこれで。
以前Monaで話だけ出ていて立ち消えになった、「S式によるIPC」を想定したシステムに方針を転換して、

• 普通の処理は普通のScheme、
• DSPやGPUでの処理を負担する小規模なScheme(系の別の言語) ← この辺を狙う

という感じで複数のScheme処理系を平行して動かそう。と。
ひとつのScheme処理系に乗せるのも悪くないアイデアだけど、継続とか他のsexyなオブジェクトを異なる種類のプロセサと共有するのは非常に難しいし、GCの問題も有るので、早いうちから複数のVM実体によるシステムデザインに関して考察しておくのは悪いことじゃないと思う。

• http://code.google.com/p/termite/

たとえばGambit上で動くTermiteはメッセージパッシングによる分散プログラミングに関して考察している。実装をチェックする意義が有るかも知れない。

ミッション

しかし、残された時間は半年くらいしか無いので、問題を次のように分割して前半だけを評価する。

• A: 明示的に記述されたデータ構造を実現するコードを生成するscheme実装
  • A': LLVMとの統合(による、ステートマシンの高速な実現)と、SIMD-awareな処理の最適化 ← この辺を考える
• B: schemeコードから適切なデータ構造を自動で構成するscheme実装
  • B': schemeコードから適切なGCタイミングを生成する

BやB'は現在でも(多分)活発な分野なので、他の研究成果を引っ張ってくるだけで十分に思える。
最初の重要な課題は、言語要素を受け入れ可能なレベルまで削ることになる。
たとえば、プロトコルの処理では定形ステートマシンの状態変化を多く持つので、純粋なCPS Schemeよりも、せめてグローバル変数くらいは欲しい　といったプロトコル処理特有の要求がある。

*1:Ypsilonのロゴがうらやましいから。もっとも、Ypsilonのyは作者の名前に由来する。