Ajisai コンパイラ育成日誌 第4日 構文解析
(今回のコード: day001-010/day004 )
前回は字句解析器(の原型)を作りました。今回は構文解析以降のステップを作っていこうと思います。
その前に、コードの見通しが悪くなっていきそうなので、ファイル分割をすることにします。分割後のディレクトリ構成は以下の通りです(parser ディレクトリ以下の定義は parser/mod.ts で export しています):
(今回のコード: day001-010/day004 )
前回は字句解析器(の原型)を作りました。今回は構文解析以降のステップを作っていこうと思います。
その前に、コードの見通しが悪くなっていきそうなので、ファイル分割をすることにします。分割後のディレクトリ構成は以下の通りです(parser ディレクトリ以下の定義は parser/mod.ts で export しています):
(今回のコード: day001-010/day003 )
前回はファイルからソースコードを読めるようにしたのでした。ただ、普通のコンパイラがやるような解析や変換はまだ何も行なっていません。そこで、今回は字句解析器を作っていきます。
とりあえず字句(トークン)の型を考えてみます:
type Span = {
srcPath: string;
srcContent: string;
start: number;
end: number;
};
type OpToken = {
tag: "+" | "-" | "*" | "/" | "%";
};
type ParenToken = {
tag: "(" | ")";
};
type IntToken = {
tag: "integer";
value: string;
};
type Token = (IntToken | OpToken | ParenToken) & { span: Span };
Span 型は、後でエラー表示をするときに、エラーが起きた箇所のソースコード中の位置を表示できるように、関係する情報をまとめた型です。各種トークンが共通して持っているフィールド span に格納されます。
前回は、以下のC言語のソースコードをファイルに書き出して、それをコンパイルするだけのプログラムを書きました:
// C 言語のソースコード
const cSource = `#include <stdio.h>
int main() {
printf("%d\\n", 42);
return 0;
}
`;
まだ Ajisai 言語がどんな言語仕様なのかといった議論は何もしておらず、無から定型の実行ファイルが生成されるだけの、全く自由のないコンパイラ(?)です。ここで、とりあえず整数値の 42 の部分だけを抜き出して、Ajisai 言語のソースコードと言い張ってみましょう:
ご無沙汰しておりました。気づけば 2025 年も半分以上が過ぎてしまいました。2025 年の目標記事は出さずじまいになってしまいましたが、2024 年の目標をそのまま引き継いでいる感じなので、結局のところ特に書くべきことはなかったと思います……。
(昨年の目標記事はこちら)
まずは 2023 年を振り返ります。
2023 年になりました。ということで、今年は何を目指そうか考えてみたいと思います。
「Trickle」というサービスを使い始めてから4年が過ぎました。このサービスは、自分の理解では以下の2つの機能を併せ持つサービスに見えます: