プロジェクト - Pleiades v0.2

Tapioca 処理系設計ドキュメント（設計思想の深掘り草案）

1. 処理系の根本思想

Tapioca は、「すべてを Table によって構成する最小限の仮想機械と言語」を目指している。VMと言語が密接に設計されており、VMの構造・API・制限がそのまま言語構文や型表現、実行モデルに反映される。これは構造の整合性と学習コストの最小化を狙った設計である。

TapiocaVM は、QEMU や Docker のような仮想プロセッサ／仮想 OS ではなく、JVM や YARV、ZendEngine のように高級言語の制御構造とデータ抽象のために設計された「プログラム仮想機械」である。命令セットや型、ランタイムの責務はプログラムの構造と実行を制御するためのものであり、システム全体の仮想化は対象としない。

この処理系は、ホストアプリケーションに組み込まれることを前提としており、データ処理や記述制御のための軽量なスクリプト環境を提供する。また、TapiocaScript は Lua や JavaScript に対抗しうる埋め込み用言語として設計されている。

2. 実行モデルとVMの役割

Tapioca VM は、レジスタベースの仮想マシンであり、すべての命令は32ビットで固定長として表現される。命令の最上位8ビットは opcode に固定され、残りは命令形式（ABC / ABx / AsBx）によってレジスタ番号や即値などとして解釈される。

VM のメモリモデルは、次の3種類に分かれる：

  • 定数プール：不変な即値や関数ポインタを格納
  • 実行レジスタ：関数単位に動的割当される 0-255 の仮想レジスタ
  • グローバルテーブル：全プログラムから参照・操作可能なトップスコープ

バイトコードは ELF に似たセクション構造で構成されるが、実体は TABLE/ARRAY によってすべての構造が記述される。VMは自身でネイティブモジュールをロードする機能を持たず、すべての拡張やインタフェースはホストから vm_global_set によって注入される。

プログラムの起動は、グローバルテーブルから関数オブジェクトを取り出し、vm_call() により実行される。REPL による逐次実行や AOT/JIT による最適化も、安定したバイトコード設計を前提として将来的に支援される。

3. 値と型のモデル

すべての値は型タグ（TypeTag）によって分類され、内部的には 64bit 整数もしくはポインタ参照で統一管理される。代表的な型は次の通り：

  • 整数：INT8 / INT16 / INT32 / INT64（すべて int64_t として表現）
  • 浮動小数点数：FLOAT16 / FLOAT32 / FLOAT64（IEEE準拠）
  • 任意精度数値：NUMERIC（内部でGMP風構造を持つ）
  • 文字列：STRING（長さ固定、UTF-8）
  • 配列：ARRAY（順序付きリスト）
  • テーブル：TABLE（文字列／整数キーによるマップ）
  • オブジェクト：OBJECT（TABLE をベースに拡張。prototype方式とGo構造体方式を選択可能）
  • 関数：ROUTINE（関数定義）/ CLOSURE（環境付き関数）
  • 外部オブジェクト：EXOTIC（FFI用の外部バインディング）

変数には型がなく、型は常に値の側に付く。型付きリテラルとして i32:314 や f32(3.14) のような記法が存在し、暗黙の型変換は禁止される。

4. グローバルスコープと実行スタイル

Tapioca では、すべてのトップレベル定義はグローバルテーブルへの代入として記述される。関数や変数は = によって定義され、エクスポートは export() によって行う。構文糖衣（export fn など）は存在せず、常に明示的な代入と呼び出しで構成される。

main = function () {
    print("Hello Tapioca");
};

export(main);

ホストアプリケーションからは vm_global_set(vm, key, value) や vm_call(vm_global_get(vm, key)) のような形で制御可能である。

5. 標準ライブラリの階層構造

Tapioca 処理系では、標準ライブラリを以下の3段階の優先度で構成する方針である：

  • 最低限（必須）:

    • Array や Table の操作（length、insert、remove など）
    • 文字列処理（substr、split、replace）
    • 基本的な数学演算（Math.sin、Math.floor など）
    • この層がなければ、Tapioca で汎用的なプログラムを記述することが困難となる

  • 推奨（基本装備）:

    • 日時処理（Date.now、Date.toString）
    • エンコーディング処理（JSON encode/decode、Base64 encode/decode）
    • 実装環境によっては省略可能だが、基本的に存在を想定してよい

  • 拡張（処理系依存）:

    • ファイルI/O、コンソール入出力（console.log、io.read）
    • ネットワーク機能（net.connect、http.request など）
    • これらは標準Tapioca VM処理系では提供するが、環境により非対応もあり得る

6. 設計上の未確定点と今後の検討

  • OBJECT 型を prototype 継承で構成するか、Go的な構造体＋メソッド分離で扱うかは今後の検討とする。
  • SIGNATURE 型の導入と活用（型チェック／FFI境界整合／実行時検証）も段階的に検証される。
  • ローカル変数とスコープ（let や var）の導入については、ブロックスコープの導入可否含め設計中。
  • template() や import() のような構文はプリミティブ関数として扱われ、実際にはコンパイル時に変換されるダミー命令である。
  • REPL、JIT対応、モジュールローダーなどの設計は、基本構造確定後に段階的に拡張される。

このドキュメントは、Tapioca 処理系の設計意図と全体像を俯瞰し、今後の仕様策定における基盤とする。

essay Yeonji's RFC