ライブラリ構成についての提案

[marihachi]

概要

CompilerとInterpreterの2種類のクラスをライブラリとして公開する。

• Compiler : AiScriptコードから別のコードを生成する (WebAssemblyなど個別に作成)
• Interpreter : AiScriptコードを実行する

CompilerとInterpreterの内部では、それぞれ構文解析と意味解析などを行う。 → 内容が同じなのでこの部分をクラスとして切り出して、それをCompilerやInterpreterから呼び出す

構文解析と意味解析をどのように切り出す？

構文解析と意味解析を1つにして切り出す

クラス名の案:

• Backend
• Core
• Parser

構文解析と意味解析を別々に切り出す(現状)

名前も現状のまま → Parser、Analyzer

その他

ASTの解析状況で型を分けたりするなら、統合してしまうほうが良い？

[marihachi]

一つにしたほうが良い気がしてる ご意見よろしくおねがいします。

[syuilo]

おそらくMisskey含めほとんどのAiScriptホスト実装では、構文解析だけしたいとか、意味解析だけしたいとかいったユースケースはなく、単に「ユーザーが用意したスクリプトを実行したい」という目的しかないと思うから、一つにまとめた方がユーザーフレンドリーだと思う

[syuilo]

だから「構文解析と意味解析を1つにして切り出す」が良さそうだけど、良い感じの名前が浮かばないな

[syuilo]

「意味解析も構文解析(parse)内で行われる処理のひとつ」という捉え方でいけば意味解析も含めて parser で良さそうだけど

[syuilo]

構文解析ペーペーなので的外れなこと言ってたらﾕﾙｼﾃ

[marihachi]

パーサーで良いかも

[marihachi]

Parserクラスに構文解析と意味解析を統合してみた

[marihachi]

こんな感じ？

公開クラス

Compiler : AiScriptコードから別のコードを生成する (WebAssemblyはWebAssemblyCompilerなど個別に作成) Interpreter : AiScriptコードを実行する Serializer : スクリプトの短い表現のエンコーダ/デコーダ

内部向けクラス

Parser : ASTの生成・バリデーション・変形処理

[syuilo]

Parserも公開されない？

[syuilo]

あー

[marihachi]

してもいいけど、直接使われることはなさそう

[syuilo]

Interpeterから呼び出す感じかな

[syuilo]

YOSASOU

[marihachi]

シリアライザ関係も検討がいるかも

[marihachi]

Serializerはこうか： スクリプト文字列 → Parse → serialize

コンストラクタからスクリプトまたはASTを受け取れるようにすると良さそう ASTの使い回しができる

んー微妙な感じ

[marihachi]

Serializerも多分コンパイラの一種なんだよな スクリプトコード → bytecode bytecode → スクリプトコード

[marihachi]

雰囲気見えてきた

[marihachi]

ParserはPlaygroundで使っていたので非公開にするのやめるか 別に公開してて困ることもなさそうだし...