読譜活動 - ZetaSQL - AST, Expression Resolution

05:03. 雨。

さて expression の評価は大物なので、その前にパースの最初のほうをチラっと見て置くべし。

  • gen_parse_tree.py AST はやはり自動生成で, 8000 行。AST への type-safe access (this->_field = (FieldType*)this->children[i] みたいな boilerplate を省く) のと、あとは Visitor の visit を生成している。こういうの Chrome とかだとマクロで頑張ってた気がするけど、生成なのだね。二周目、三周目ならではの過剰感。
  • bison_parser.y - 9800 行! あとちょっとだ! なお duck の y は複数ファイルに分割されているのでてっきり bison にそういう機能があるのかと思っていたが、これは Python で連結しているだけらしい。しかも libpg_query ではなく duck 勢の仕業。どっちがいいのかわからんな。普通に C preprocessor くらいでいいんじゃないか・・・。
  • なお bison_parser.py のコメントは文法の曖昧なケースをきちんと解説している。全体にコメントの質の高さは特筆すべきだね Zeta. 一方 shift-reduce conflict が何だったか完全に忘れているわたくし。
  • それにしても Modern C++ を受け入れると semantic action を割と綺麗に書けるのだね。Bison never dies (in C++ land)...

まあ AST を python で生成している以外は概ね普通の作りであった。Expression の resolution に戻りますかね・・・ resolver_expr.cc

  • Proto をネイティブサポートしており、それがかなりの複雑さを積み増している。型システムの解釈には proto の descriptor が直接使われており、大変ですね感。
  • ResolveFunctionCallImpl: 関数呼び出しを眺めます。なんか flatten といのが特別扱いされているね。
  • named argument あんの?ほんとに?ほんとだ!Zeta 活動が終わったころには BQ マスターになれるかもしれないわたくし。しかし "=>" かよ・・・。
  • ResolveExpresssionArguments - そして引数の解決を見ます。これは変数の解決となんか違うのだろうか・・・というと余計なチェックが入って、あとは変数の解決である。
  • Lambda あんの?BQ にはないっぽいが、そもそも lambda を引数にとれる higher-oder function ("こうかい" が変換できない MS IME) というのは SQL の世界にあるのだろうか・・・そして SQL をパースするのはいいとしてそれを database は実装するのだろうか・・・。やばいな。まあ CREATE FUNCITON とかで作った pure SQL の関数だったらバックエンドの手前でいろいろできるのかもしれないが。
  • 全体的に警告やエラーメッセージにかなりの行数を割いていて引き続きえらいね、というかんじ。他の真面目な静的型言語のパーサも一度ちゃんと読んでみるべきだろうな。
  • 関数は overload できるので signature がある(FunctionSIgnature)。Catalog の Function は list of signatures を持っている。
  • とにかくめちゃめちゃエッジケースがあって厳しい。もはやエッジケースというレベルじゃない。だいたいこういう雑な言語は実行時(実際の評価時)にエラーを出して済ませる動的型の言語であることが多いし、世の中の SQL もそういう実装がそれなりにあるはずだが、Zeta はパースだけするというデザインの都合からそれを静的に解決しようとして複雑さを高めている。その複雑さの集積がこの 8000 行のファイルなわけだな・・・。
  • そしてこの手の巨大なファイルを読むのに VS Code は向いてないな。IDE でクラスの構造化情報が左側の pane に必要。これは VS Code のせいというよりクソデカファイルのせいだが、そういうのと戦う道具というのも必要なのだよ・・・。ただほぼ何も設定してないのに Jump to definition がなんとなく動くのはすごいよね vs code. これは traditional VS C++ toolchain の資産だよな。

はー今日はここまで。式の resolution はもうこのくらいでいいかな。無限の細部があるけど SQL 詳しくないので appreciate できる気がしない。次回は式の評価の参照実装でも覗いてみますわ。

あと宿題としてはドキュメントに目を通すというのもあるね。