Todo

ToDo #

ToDo リストです(2025/11/04)

  • field arguments の意味づけ

    • ジェネレータ側に対応させる

  • import 型の対応

    • 多段も許可?

  • union 型のメンバー

    • union 型でも a.b とできるようにする

  • 可変ビット整数型

    • swf_rect.bgn など
    • u<N> みたいな?

  • custom format の実装

    • encode と decode あとオプションで size?

  • src/core/ast/json.h のリファクタリング

    • expected<T,E> とそれを簡単にする演算子を使おうとした結果、作者ですら意味不明なものができてしまっているのでリファクタリングしたい

  • float 型対応

    • バイナリレベルキャスト?

  • src/middle 内の AST 置き換え処理をまとめる

    • 重複や、複数回の探索がコストになると思われる。まとめられる部分は一回の探索で置き換えしたい

  • パーサーを拡張可能にする

    • パーサーが拡張しづらすぎなので直す
    • LR パーサー的なものを使う? or BNF で書くだけに留める?

  • AST 定義を C++から独立させる

    • C++のコードも自動生成する?
    • 他言語でも JSON-AST を生成できるようにする。

  • input = input.subrange構文の offset は subrange がネストしたときどのように扱えばよいか。

    • subrange は input.offset == 0 のときは subrange における 0 を示す? <-これは微妙だ。これだと全入力の任意の位置は指し示せない。
    • 全体の入力の offset <-こっちが良いと思われる

  • Generics の導入?

    • Array とかに対しておんなじ形式?

  • WebPlayground を React とかモダンなウェブフレームワーク使うやつに変える

  • prefix bit + struct 型にジェネレーターを対応させる

  • WebPlayground の行マッピング(C++)を Monaco エディターの仕組みを使ったものに置き換える

    • dirty hack すぎる

  • match 文等の網羅性検査

    • enum 型向けのやつ

  • キャストの可能性判定(整数型を配列型にキャストしようとしたりを禁止?or 要素化?)

  • f :[len]u1(config.type = u32)的な構文

    • ビット列をどうマッピングするかを決定する?。
    • len が 32 ビット超えたらエラー?ビット列長条件は別途?

  • input.bit_order, config.bit_order.msb, config.bit_order.lsb の導入?

    • ジェネレーターへの対応

  • もっと自動化を推進する

    • C++部分とか

  • ビルドスクリプトの整理

    • bat とかいうレガシーシステムの使用はやめる?

  • ビットストリームへの対応

  • パーサーをエラートレラントにする

  • コメントの対応付けをする

    • 現状集めることはできるが、対応付けが曖昧

  • AST からコード復元できるようにする

    • ツールで補助?

  • input.subrange 構文で offset を指定している場合、input.peek = true と同等の扱いにする

  • state 変数に readonly 化する構文をつける?

  • available(field,Type) の構文を追加

  • union を特定の型にして使うときにはキャストで明示

  • テストの強化

    • 型づけのルールをテスト化?

  • Diagnostic mode を src2json に実装

    • ジェネレーターから位置とエラーメッセージを受け取って整形して出力?

  • config.parent[0]構文

    • 例えば親の親の親は config.parent[2]
    • cast を使って型を明示 <T>(config.parent[0]).field

  • 適切にヘッダーとソースに分割する

    • 明らかヘッダファイルである必要ないものまでヘッダファイルに書いているので直しましょう

  • ブランチベース開発スタイルに変更する

    • main に直 push はやめましょう

  • 現在存在する構文の完全なリストの作成

  • Field ノードの各フィールドの意味論をはっきりさせる。

    • 作者も混乱してきています…

  • Struct Size を 式で表現するようにする

  • フォーマット内からフォーマット外へのアクセスをステート変数を除いて制限する

  • available(field,Type)構文を if で使ったときに scope 内に元のフィールドへの参照を挿入することで直接解決する?

    • TypeScript の型ガード的なもの

  • sizeof ビルトイン関数の導入

    • type literal -> 型長さ
    • expr -> 式の型の長さ

  • 実際に使ってフィードバックを増やす

  • map 型について[]u8 で導入する気になればできそう

    • 型リテラルを index にすれば解決…
    • state 上で使う用に…
    • これ用に string 的なのもいれる?

  • 全体サイズを事前計算できるメソッドは必要そう

    • オーバーヘッドでかいかなと思ったが必要ではありそう
    • ロジック的には encode のをそのまま使えそう

  • format への引数渡し構文

    • field argument の解釈方法でどうにかする

  • ジェネリクス的なのの導入

    • array 型とかのユーザー定義型的なのをどうにかする
    • ターゲット言語に合わせてどうするか(事前展開 or ターゲット言語の generics に直すか)
    • 定数引数?
    • 方針(2026-04-10 検討): brgen middle pass で pre-monomorphize する方向で行く。EBM・全 ebm2* は無改修を目標
      • 決定打はサイズ計算の symbolic 化回避。型変数を middle pass に入れないことで、既存のサイズ計算・依存解決・状態変数解析を無改修で通せる
      • Go に const generics が無いのでどのみち monomorphize が必要、という事情もある
      • 後から C++/Rust だけ native template 出力したくなったら、EBM に TemplateDecl を上積みして fallback として pre-monomorphize を残せばよい(Phase 1 の作業は無駄にならない)
    • Phase 1 スコープ:
      • format Foo[T] 宣言のみ許可。fn 内 generic は禁止
      • 型制約は T: format のみ。sizeof(T) や type-level match は Phase 2 送り
      • 構文は Foo[T]。配列リテラルが存在しないので衝突無し。typing.cpp の既存 rewrite 機構(ident_to_type_literal / call_to_cast / typing_index)と同じ理屈で expr 位置はほぼ無改修
      • 型位置は parse_type (parse.cpp:1159) の IdentType 生成後に 10 行程度足して [...] を受ける
      • middle pass の最初で instantiation 閉包計算 → deep copy + substitute → 具象 format に展開
      • AST ノード追加は ./build.bat generate で astlib 側は自動追従

  • カスタムフォーマットとかでエンコードしたバイナリ列の取得とかデコードしたバイト列から構造体にするみたいなのを簡単にする構文を導入する?

  • slice 構文の導入?

    • slice ってのをどう扱うか

  • 構造体リテラル式(struct literal)の導入

    • fn 内で Foo{field: value, ...} の形式で format 型の値を構築できるようにする
    • 主な用途: テストケースの記述、デフォルト値ファクトリ
    • 意味論: brgen の既存哲学(ユーザが全フィールドを明示、consistency は encode 時検証)を踏襲。逆推論や solver は導入しない
      • arp.bgn のように 1 個の length が複数配列を制御するケース、tcp_segment.bgn のように length が式に埋め込まれるケースを考えると、逆推論は一般には不可能
      • length 系フィールドは .length 構文で参照すれば verbose さを緩和できる
    • 固定値フィールド(magic :u32(0xCAFEBABE) 等)はリテラルでは省略可とし、自動で埋める。明示した場合は期待値との一致チェック
    • 段階的実装案:
      1. プリミティブと固定長配列のみ対応
      2. 可変長配列対応(length との整合性は既存 encode 時検証に委ねる)
      3. ネスト format の再帰的リテラル
      4. fn の引数/戻り値で format 型を扱えるようにして、ライブラリ化
    • 実装箇所: brgen 本体のパーサ・AST・typing、rebrgen 側は EBM に StructLiteral 式を追加して各 ebm2* で言語別の初期化構文を生成

Done リスト #

  • float 型(f32 と f64、f80 や f128 なども?)
  • 現状はただの引数だが、固定値(整数型)、引数(format 型)、アラインメント指定(共通)、サブレンジ(共通)などの対応
  • state 変数の使用の検出と依存関係解決
  • AST のドキュメント
    • 自動生成したい
  • input.bit_order, config.bit_order.msb, config.bit_order.lsb の導入?
    • gzip とかでのハフマン符号化の格納とか?
  • WebPlayground 上で example を触れるようにする
  • any match(..)が必ず最後にあるかを検証する
  • match 文等の網羅性検査?
    • サイズの決定のために
    • 現段階ではサイズが決定可能かつ any match があるときのみサイズを設定?
      • あとは u1 くらい単純なやつ?
  • char 型の導入,char リテラル
  • import 型の対応
    • i.Type 的なものを。段階は 1 段階のみ
  • enum に文字列を割り当てる構文
    • a = 1, "a" みたいな
  • input.peek = true を指定している場合、フォーマットのサイズ計算から除外する
  • input = input.subrange(len,offset)で offset 指定されたときフォーマットのサイズ計算から除外する
  • フィールドにステート変数かどうかを示すやつを追加?