Wasmで拡張できる軽量マークアップ⾔語Brack(前編)

第14期サイボウズ・ラボユース成果発表会
https://cybozu.connpass.com/event/347931/

浅田 睦葉

Transcript

1. Wasmで拡張できる 軽量マークアップ言語 Brack (前編) 第14期サイボウズ・ラボユース成果発表会 2025.03.28 浅田睦葉 @mutsuha_asada GitHub
2. 2 @momeemt @mutsuha_asada https://momee.mt 浅田 睦葉（Mutsuha Asada） 🎓 所属 ・筑波大学情報学群情報科学類 B3 🐣 興味があること ・コンパイラやそのツールチェーン（LSP、サニタイザ） ・ビルドシステム（Nix, Meson, etc...） 🍳 趣味 ・音楽、お笑い、料理など 自己紹介
3. 概要 3 ・開発中のマークアップ言語についてお話しします 📚 目次 マークアップ言語を自作する背景 1. 言語仕様とプラグインシステム 2. ブログジェネレータの実装 3. ビルドツールの実装 4. 展望とまとめ（前半） 5. Language Serverの導入 6. パーサの概要 7. エラートレラントなパーサの実装 8. 展望とまとめ（後半） 9.
4. 1. マークアップ言語を自作する背景 4
5. 軽量マークアップ言語を自作する背景 5 ・ブログを書くため 　・ 🤔「自作言語でブログ書きたくね？」 　・最初は雑な思い付き ・たいていの場合はMarkdownが採用される 　→ Zenn、Qiita、GitHub README、その他、etc... 　 👍 データ記述の整合性を保ちつつ、ソースコードの可読性も意識されている 　 😞 ブログの場合には変換後のコンテンツのみが重要 + 多様な表現力が求められる 　 😞 標準的で明文化された仕様を持たないので方言が無数に存在 1. マークアップを自作する背景
6. Markdownクイズ 😄 6 ・Markdownはオフィシャルな統一された規格が無く、 　CommonMarkやGitHub Flavored Markdown(GFM)などの後発の規格がいくつかある 　→ 脚注はCommonMarkに定義されている？GFMには？ 　→ インライン脚注はpandocで変換できる？ 　→ リストの要素に見出しを含めてMarkdown.plで変換できる？CommonMark準拠だと？ 　→ MultiMarkdownを使うとルビを振ることはできる？ ・我々はMarkdownの枠を超えた表現力をMarkdownに要求している まあ確かに欲しいよな 知人のMarp製スライド pタグを省略できる JSXであるところのMDX 1. マークアップを自作する背景
7. 1. マークアップを自作する背景 Markdownクイズ 😄 7 ・Markdownはオフィシャルな統一された規格が無く、 　CommonMarkやGitHub Flavored Markdown(GFM)などの後発の規格がいくつかある 　→ 脚注はCommonMarkに定義されている？GFMには？ 　→ インライン脚注はpandocで変換できる？ 　→ リストの要素に見出しを含めてMarkdown.plで変換できる？CommonMark準拠だと？ 　→ MultiMarkdownを使うとルビを振ることはできる？ ・我々はMarkdownの枠を超えた表現力をMarkdownに要求している まあ確かに欲しいよな 知人のMarp製スライド pタグを省略できる JSXであるところのMDX 変換規則・対象を拡張することを 前提にしたマークアップ言語が欲しい
8. 作りたい言語のイメージ 8 ・言語仕様に特定の装飾が含まれない ・コマンドはモジュール名 + コマンド名 + 引数からなる文字列置換メカニズム ・コマンドは外部プログラムの呼び出しによって実現する 1. マークアップを自作する背景
9. プロトタイプ (2022) 9 ・Nim言語で、Nimの関数を呼び出すBrack言語とブログジェネレータを実装 　→ 詳しくはこの記事を読んでください 1. マークアップを自作する背景
10. プロトタイプ (2022) の評価 10 ・ 👍 良い点 　① 毎日の日報を書くためのブログ言語として十分に動作する 　　→ https://blog.momee.mt はこのプロトタイプで動いている 　② コマンドとマクロが実装されており、Nimの関数で直感的に書ける ・ 😞 改善するべき点 　① 独自のコマンドを実装するためにはNimを書かなければならない 　② プラグインが静的に解決されるため、追加・削除するにはビルドし直すしかない 　③ ブログがNimが提供する謎のテンプレートエンジンによって生成されており、 　　現代的なフロントエンド技術と組み合わせることが難しい 　　→ 真面目に動かすには車輪の再発明をたくさんしなければいけない 1. マークアップを自作する背景
11. 2. 言語仕様とプラグインシステム 11
12. 12 プラグインシステムの変更 ・2023年12月ごろに友人（上野）がBrackの開発に関心を示した 　→ まずは問題点①、②を解決してからチーム開発を始めることにした ・動的にプラグインをロード・実行できる仕組みを入れる 　・選択肢 　　・動的リンク（so, dylib, dll） 　　・Luaなどのスクリプト言語のランタイムを組み込む 　　・VM言語で実装し直して、中間形式をプラグインとして扱う（JVM、.NETなど） 　　・WebAssembly 　・Wasmは移植性が高く、サンドボックスモデルを持つ 　　→ 将来的なエコシステムの拡充も見込める 　　・これを入れよう！ 2. 言語仕様とプラグインシステム
13. 13 Nimのことはもう忘れても大丈夫です 🥲 ・Wasmをプラグインとして扱うためのフレームワーク、Extism 　・少ないコードでホスト + プラグイン側の実装が可能 　・Rustで実装されたライブラリだった 　　→ ので、コンパイラもRustで実装し直すことに ▲ 2日で実装が急にRustに書き換わる 2. 言語仕様と プラグインシステム
14. Extism Wasmtime (Wasm Runtime) 実 行 Brack Compiler 解析・AST化 必要な関数をコール 呼び出し・ABIの解決 (実行時) 14 Wasmを用いたプラグインシステム Brack文書 プラグイン 様々な言語から コンパイル 2. 言語仕様とプラグインシステム
15. 15 コマンドとマクロ ・コマンドは単なる文字列の置換メカニズム 　→ 脚注のような複数の要素にまたがるコンテンツを実装できない ・マクロ 　・マクロはコード生成前に、ASTを渡してのぞみの構造に変換して返す 　　→ より自由なコンテンツを生成することができる 2. 言語仕様とプラグインシステム
16. 3. ブログジェネレータの実装 16
17. 17 旧来のブログジェネレータ ・プロトタイプでは生成したHTMLを 　Nimのテンプレートエンジンに埋め込んだ 　→ GitHub ActionsでHTML/CSS/JSを 　　生成して配信サーバでホスト 👍 コンパイラが吐くHTMLをそのまま使える 😞 モダンなフロントエンド技術との 　相性が悪い 3. ブログジェネレータの実装
18. Brack Compiler HTMLを生成 Blog Generator JSONに変換 18 実装したブログジェネレータ ・モダンなフロントエンドと組み合わせるためにJSONを出力 　→ Next.jsプロジェクトをテンプレートにしてブログ記事を描画 記事データ fetch フロントエンド 👍 フロントエンドとBrackを分離できているので フロントエンド技術自体はなんでも良い 3. ブログジェネレータの実装
19. 19 生成されるブログ ・素のBrack文書から右のようなブログ記事を出力できる 　→ フロントエンドは既存の資産に乗っかった上で 　　開発できるので旧ブログのような辛さが全くない ・単に記事データのJSONをパースして描画するだけなので 　自分でデザインを自由に決めることができる 　・謎のテンプレートや規約に乗っかる必要がない 　→ WordPressなどのCMSと比較した嬉しさ
20. 20 容易なデプロイ ・公式で定義したActionを 　呼び出すだけでデプロイ完了 ・以前より簡単に技術ブログを 　始めることができる 3. ブログジェネレータの実装
21. 4. ビルドツールの実装 21
22. 22 ビルドツールの必要性 ・以前はNimプログラムをビルドする際にプラグインも解決されていた 　→ しかし、新しいコンパイラは実行時にWasmバイナリを読みに行く 　・プラグインのパス、依存関係や文書の設定を記述できるビルドツールが必要 ・どんな要求を満たしたい？ 　・1バイナリであること 　　→ 軽量マークアップ言語を使いたい人が文書を書くことに興味があるのであって 　　　残念ながら複雑なビルドやインストール工程には興味がない 　・グローバルを汚染しないこと 　　・Wasmバイナリは1つ1つが軽量なのでプロジェクトごとに用意しても問題ない 　・エラー報告がわかりやすい 　・設定ファイルはtomlで書きたい 4. ビルドツールの実装
23. 23 4. ビルドツールの実装 ビルドツールの必要性 ・以前はNimプログラムをビルドする際にプラグインも解決されていた 　→ しかし、新しいコンパイラは実行時にWasmバイナリを読みに行く 　・プラグインのパス、依存関係や文書の設定を記述できるビルドツールが必要 ・どんな要求を満たしたい？ 　・1バイナリであること 　　→ 軽量マークアップ言語を使いたい人が文書を書くことに興味があるのであって 　　　残念ながら複雑なビルドやインストール工程には興味がない 　・グローバルを汚染しないこと 　　・Wasmバイナリは1つ1つが軽量なのでプロジェクトごとに用意しても問題ない 　・エラー報告がわかりやすい ベースは`cargo`コマンド CLIコマンドは`go`コマンド を目指した作りにしたい
24. 24 CLIとLanguage Server、デバッグの抽象化 ・CLIとLanguage Server、デバッグはそれぞれ「データの文字列加工屋さん」 　・ロガーをそれぞれ独自に実装して、プロジェクト管理クレートに渡してあげると 　　上手く抽象化できる brack-cli brack-project brack-language-server debug brack-tokenizer brack-parser brack-codegen ここで必要な情報を集めて整理する 👉 4. ビルドツールの実装
25. 25 Cargo.toml風の設定ファイル 4. ビルドツールの実装
26. 26 動作の様子 4. ビルドツールの実装
27. 5. 展望とまとめ（前半） 27
28. 28 展望（前半） ・CLIが充実してきたらv0.2.0を打ちたい、3〜4月中を目標にする ・今まではエラー報告がわかりにくくインストール工程も複雑だったのであまり 　積極的に宣伝してこなかったが、そのタイミングでdev.toやHackerNewsなどに 　投稿してフィードバックを得たいと考えている ・今のコンパイラを自分のブログ（blog.momee.mt）で実用できるようにしたい ・Brackのプラグインを実装するためのライブラリはExtismを 　薄くラップしたもので、Nimで実装していたころより遥かに複雑なので 　改善していきたい ・ブログのデプロイをさらに簡易化して、友人にブログジェネレータを使って 　ブログを書いてもらいたい 　→ 現在はジェネレータとコンパイラが分かれているので統合する 5. 展望とまとめ（前半）
29. 29 まとめ（前半） ・Wasmで変換規則を拡張できるBrackという軽量マークアップ言語を作っている ・ブログを書くための言語として作っていて、将来的にはスライドやPDFも吐きたい ・元々はNimで実装していて、定義したコマンドをコンパイル時に結合して実現して いたが、① ライブラリの実装者がNimを書かなければいけない ② ライブラリが増減 するときにビルドし直さなければいけない ③ Nimのテンプレートエンジンに密結合し ておりモダンなフロントエンド技術と組み合わせるのが困難という問題があった ・そこでWebAssemblyをプラグインとして利用するコンパイラをRustで書き直した ・ブログジェネレータが生成したHTMLをJSONに変換するようにしたので、モダンな フロントエンド技術と組み合わせることが容易になった ・ブログを書くためのCLIやデプロイワークフローについても実装した ・ビルドツールの実装をしていて、使い勝手はCargoに近く、1バイナリで完結する点 やコマンドのインタフェースはGoに近いものを目指している 5. 展望とまとめ（前半）