mutsu の 2026/10 時点での目標

ecosystem が動く割合が 70% を超えることが当面の目標だったのだが、それはあっという間に超えてしまった。

現在、いくつかのアーキテクチャ規模の改善を実施中である。

nqp:: カバレッジの増大

nqp:: なメソッドは MoarVM の内部 opcode を直接呼ぶ関数なわけだが、Raku module の中にはこれに依存しているものが多々ある。 (これを利用しないと高速なコードが書けなかったため、かな?)

なので、これをひと通り実装する必要がある。

Interpreter オブジェクトの分割

Interpreter という struct があるのだが、ここになんでもかんでも詰め込まれていて、数百 field がある神オブジェクトになっていた。 これを、適宜分割していっている。

そもそもこの規模の rust project だと、crate を分割することを考えた方がいいのだが、それにあたって、神オブジェクトがあると管理しづらいというのもあり、こういうリファクタリングが必要となっている。

regexp engine の VM 化

regexp engine が、tree walking だったのを VM にしようとしている。 どうしても regexp engine が遅いので、最適化の一貫として VM にしていっている。

これ系は、やるならさっさとやっていく必要がある。 二重に管理していると、バグ修正も両方にやったりしがちでコストが増大するため。

組み込みメソッドの管理方式変更

初期の頃より、組み込みメソッドは string を switch でやる方式になっていた。 が、この方式だと、.^can の実装ができない。。というか実際、実装とずれがちだった。AI は気合でこういうのを言われたタイミングで追加する、とかはしてくれるのだが。。どうしてもズレる。 なので、このへんの処理を変えていく必要があるという形。

機械的にやっていくだけではある。

check-scan-names の件

${pkg}::${method} の組み立てが各所で行われていて、それを Symbol::intern しまくるので無駄が大きいという件。 ちゃんと適宜キャッシュしながらやるなどして、高速化をはかっているとちゅう。

これも機械的に置換していくだけ。

RakuAST キャンペーン

rakudo は RakuAST を構築してから QAST を構築する形になっている。 mutsu でも同様に RakuAST を構築してから internal AST に構築する形をとる形式に変更予定。

そうしないと、RakuAST 自体が今後は露出していく形になるので、整合性が取れない。

Published: 2026-10-04(Sun) 07:15