8/22から8/25の4日間、大阪Ruby会議04に参加するために大阪へ行ってきました。 大阪Ruby会議への参加は昨年の大阪Ruby会議03以来なので1年ぶり2度目でした。 今回は基調講演の依頼を受けていたので登壇者としての参加となりました。
事前にタイムテーブルで他の登壇者や発表の概要を見ていたので、技術寄りのコアな発表が多い会議になるのではないかと想像していました。 結果的には想像以上に濃い話を聞くことができました。全体として笑いにつつまれた発表の多い、良い大阪Ruby会議だったと思います。
会期前後の様子はハッシュタグ #osrk04 で追うことができます。
基調講演「最高の構文木の設計 2024年版」
私と構文木
普段はparserやparser generatorの探求と開発をしている私ですが、構文木との関わりが全くないわけではわけではありません。 例えば過去にはRubyのNodeに位置情報を持たせるという大規模な変更をいれたこともあります1。
また他の言語のparserを読んだりすればそこでは構文木が作られているわけです。 なのでそれなりに構文木は読んでいるはずです。 しかし読めども読めども構文木に原理原則や設計方針があるように思えず、あまり深く関与しないようにして今日まで生きてきたのでした。 とは言ってもいつまでもそのように避けていることもできないので、今回腰をすえて構文木のユースケースを収集・分類し、それらのユースケースをカバーできる骨子となる設計について考えることにしました。
Red Green Treeは知っているけれど
LSPを視野にいれないといけないこの時代に構文木について調べれば、C# (Roslyn)で採用されているRed Green Treeという実装にたどり着くことでしょう。 そしてRed Green TreeがC#だけでなくSwiftやrust-analyzer、Biomeなどで使われていることがわかります。 それらの実装ではRed Green Treeがどのようなものかといったことが詳しく書かれており、Red Tree, Green Tree, Triviaというキーワードについて知ることもできます。 しかしこのRed Green Treeという実装の何が優れているのか、何が肝なのかを調べてもどこにも書かれてないのです。この点がわからないといざ自分で技術選定するときにどこのあたりがコアでどこは変えることができるのか分からなくて途方に暮れてしまいます。
ではどうするか。ユースケースを集めて自分で色々と設計をしてみればいいのです。
そしてそれぞれの設計がユースケースをカバーしているか、無駄のない設計になっているかを確認します。
そのようにして設計を検証するなかで新しい疑問が出てくることもあるでしょう。
例えばRed NodeもGreen Nodeもimmutableなデータ構造なのであれば構文木の書き換えるたびに対象のノードからルートノードまでの全てを再作成することになり、無駄が多いのではという疑問が生まれます。
そこでswift-syntaxの実装をみるとSyntaxRewriterが提供されていて、SyntaxRewriterを継承したクラスでは都度ルートノードをつくり、SyntaxRewriterがそれらをつなぎ合わせて下から少しずつ構文木全体を再構築することで無駄なノードの作成を回避していることがわかります2。
このようにユースケースと設計を行ったり来たりするなかで徐々にその設計のポイントがはっきりとしてきます。
今回の発表はいろいろな解釈があると思いますが、Rubyの構文木のあるべき姿を提示する発表とも、Red Green Treeで失われてしまった設計とユースケースの繋がりを見つけにいく発表とも捉えることができるのではないでしょうか。
完走した感想
技術的な内容に完全に振り切った発表ができたと感じていてとても満足しています。 ここまで詳しい構文木の話はおそらく聞いたことないと思うので、みなさんに新しい風景を提供できたのではないでしょうか。
また今回の発表で使ったスライドや発表前日に公開したブログ記事が、Rubyに限らず構文解析や構文木について関心を持っている人に幅広くリーチしているみたいで嬉しいです。
今回スライドに使った写真はそれぞれ
で、全て現地調達しました。
セッションについて
ぺんさんの発表は、複数の要素を画面上に意図した通りに描画したいがやたら実装が複雑になってしまっているという状況を前に、3D renderingという既知の問題に結びつけてそこで使われているアルゴリズムを適用することでコードの見通しをよくするというお話でした。 問題をグッとみたうえで、似た問題とその解決策を試してみるという点に、"たしかにそうだよなー。わかるー"と思いながら聞いていました。 華麗な伏線回収と大阪ならではのネタが散りばめられていて、軽快なリズムで進んでいく発表でとても楽しかったです。
junk0612さんの発表は手書きでLR parserをつくるという発表で、どうしてそうなった...という気持ちで見ていました。この発表が個人的に一番爆笑した発表でした3。次回は構文木生成をするとのことなのでどのような構文木を作るのか楽しみです。
jokerさんの発表はgemをRustで書くときの話で、いろいろ踏んで試行錯誤している姿がまさにjokerさんという感じでいい発表でした。 個人的にはメモリ管理とGCの大変さの方に直面している仲間としてニコニコして聞いていました。頑張っていきましょう。
koicさんの発表についてはminifierも構造化された情報がほしいでしょう？ という気持ちで聞いていました。その一方でコードの書き換えが意味を変えていないか事前に簡単にわかる方法を構文解析のレイヤーは提供できないのですか？という問いがあるんだなと気づくきっかけになる発表でした(koicさんはそんなことは一言も言ってない)。
hasumikinさんのキーノートはまさにhasumikinさんのキーノートでとても楽しかったです。僕が台湾で何か言ったという話があって、"ん？そんなこと言った記憶全くないが？"となったので懇親会でkoicさんに裏取したところ"普通にそう言ってましたよ!?"と言われたので、単に僕の記憶力が悪いだけでした... 台湾の話でいうとhasumikinさんのRubyKaigi 2024のスライドに台湾で撮った写真が出てくるのですがそちらの記憶も全くないので、台湾の地下のお店で飲んだ時の記憶がだいぶ怪しいということがわかりつつあります。
大阪Ruby会議04で何を話すのいいかなと考えていたころ、"曲のキーというのがあるように、キーノートはそのカンファレンスの色を決めるものですから"と何度かkoicさんに言われていました。 この言葉が腑に落ちないまま当日まで過ごしていたのですが、いまこのブログを書く段階になってようやくその意味がすこし分かった気がします。 これは単純に大阪Ruby会議04の発表内容に構文解析やparser, lexerの話が多いということではなく、それぞれの発表が互いの発表と緩く繋がっていて、そのなかでも"あえて"今回のカンファレンスをまとめるときのキーワードが基調講演だったりするということかなとぼんやり思っています。
カオスのなかにパターンをみつけて少数の原則で解決するのはとても楽しいし、「役に立たない」話もまたとても楽しいのです。
旅程
備忘録も兼ねて時系列でも振り返っておきます。
Day -1 (8/22) - いざ大阪へ
大阪へ移動しました。行きは用事があったので一度京都でおりて、用事を済ませた後に阪急で梅田まで移動しました。 その後梅田でも用事を済ませて知人から教えてもらったお店に行ったりしていました4。
Day 0 (8/23) - 写真をとりに南へ北へ
前日入りする人が移動中に楽しめるように Ruby Parser開発日誌 (19) - 最高の構文木の設計 2024年版 - かねこにっき を公開しました。 内容が好評でDay 0の飲み会でさっそくonkさんに絶賛してもらって、へへへってなったりしていました。 ブログは発表内容の6割くらいが書かれているので、Day 0にブログを読んで完全に理解した人でもちゃんと発表が楽しめるような安心設計になっています。 むしろブログを理解すると出てくるであろう疑問が発表で解決されるようになっているはずです。
ブログ公開後は反応をチラチラみながらスライド用の写真をとりに大阪を南へ北へと移動していました。 今回は主に以下の場所に行ってきました。
- 心斎橋
- 新世界
- 万博記念公園
太陽の塔の内部に入れるのを現地で知ってはしゃいだりしつつ、梅田に戻って友人と音ゲーをし、最後はydahさん主催の飲み会にいってました。
Day 1 (8/24) - 大阪Ruby会議04
基調講演をしたりしてました。 会場が文字通り美術館の隣でいきなり緊張したのを覚えています。 そもそも中之島のほうにいったことがなかったので、綺麗な街並みだなーなど思っていました。 カンファレンスも物理的にも暑い一日でした。
Day 2 (8/25) - 大阪観光
大阪Ruby会議04 を 256倍 楽しむための記事 - ANDPAD Tech Blogで紹介されていた喫茶 水鯨に行って朝ごはんを食べ、フクロウTシャツを買いにho-ho-〜ふくろう雑貨とまったりスペース〜に行きました。 特に朝ごはんは自由度が高く、せっかくなら現地に詳しい人がおすすめする喫茶店で食べたいなーと普段から思っているので、この特集記事にはお世話になりました。ありがとうございます。
帰ってからは新大阪駅で買ったりくろーおじさんのチーズケーキをもしゃもしゃ食べています。
私と大阪
最初に就職した会社が大阪のメーカーだったこともあり、以前3年ほど大阪に住んでいました。 当時はエンジニアではなく経理をやっていましたが、プログラミングの勉強を始めたのは大阪時代のことです。 初めて参加したRubyの勉強会も大阪のイベントでしたし、初めて参加したカンファレンスも大阪でした5。 そのため自分にとってエンジニア人生と大阪は深く関係しています。 いまでもあのとき住んでいたマンションの一室で興奮しながらRHGを読んでいた時のことを覚えています。 そのため今回大阪という場所で地域Ruby会議の基調講演をするということには結構思い入れがあったのでした。
すごく楽しいカンファレンスでした。スタッフのみなさん、登壇者のみなさん、参加者のみなさん、ありがとうございました！！！
- RNode with code positions - RubyKaigi 2018を参照↩
- 最高の構文木の設計 2024年版 - Speaker Deck 130枚目以降でこの話にふれている↩
- LR で JSON パーサーを作る / Coding LR JSON Parser - Speaker Deckのこと。発表の枠はSponsor LTということになっているが9割くらいJSON parserの実装の話をしている。非カーネル項/カーネル項を説明なしで使うスライドを自分は作ったことがないので精進します...↩
- 用事とは行脚のこと↩
- PHPカンファレンス関西2013のこと。このときの発表のなかで"いま東京ではRubyKaigiをやっていますが"という話があって、そこで初めてRubyKaigiという単語を知った↩
