妄想設計第一

華和梨
  • Statementを、コード/構文木/データで構成
  • データセグメントには文字列が入る
  • コードと構文情報がそれぞれデータセグメントを参照
  • データは辞書全体で共有した方がサイズ的に有利
    • 現在のStatement単位の参照カウント管理と競合して、GCの実装が面倒になる。というか遅くなる。
  • 基本はスタックマシン
  • でも変数アクセスが必ず連想配列なんだが。メモリが汚れるなあ。
  • 構文木を別枠に出したので、晴れて堂々とブロック用フレームを多用可能。そればかりか自由に最適化可能。
  • ブロックから戻るときにオペランドスタックの残りカスを結合して出力にする

あくまで妄想。
ようやっとlexerの多言語対応化までできたので、少し浮かれているのかも知れない。iconvみたいなI/Fのプラグインで複数のコードに対応する(プラグインdllを書かなければならないが)。ただしコード変換はサポートしていないので、同一エンジン内では、辞書から出力までコードは一貫しなければならない。コード変換は入出力I/Fでやるべきという判断(例えばProxy SHIORI、幸水)。あとは

  • ASCII以外のイベント名 (まあまず無い)
  • 辞書以外(KISでの)ファイルI/O (これはちょっと問題かも？)
  • 正規表現？ (うぐぅ)


いつまで経っても黒姉/御影黒姉が好きだなぁ。この病気は治りそうにない。