mimiumへのトランスパイラmmmmをつくっている
mimiumへのトランスパイラmmmmをつくっている
今回はこのプロジェクトについてのお話です。
つくった動機とか今後とかをメモっておく用途です。
mmmmとは
勉強用につくった、独自言語(mmmm言語)から音楽プログラミング言語mimiumへのトランスパイラです。mimiumは松浦知也さん絶賛開発中の音楽プログラミング言語です。mimiumについては以下の拙作の記事を参照してください。
で、mmmmとは何かというと、上記記事にも書いた問題点
ちなみに現在は「状態を閉じこめたオブジェクト」(たとえばクラスやレキシカルクロージャなど)に類するものはまだないので、上のシーケンサ的な状態を持つプログラムを複数つくるときには、実際に状態変数を必要な数だけ定義する必要があります。
をなにかしら(一時的に)解決するものとして、またあるいはコンパイラの勉強用として、作ってみるかーとやってみたプロジェクトです。「mmmm言語からmimiumへのトランスパイラ」と書きましたが、実際には現状ただのmimium→mimiumコンパイラというか、雑魚フォーマッタみたいなことになっています。
mmmmの動機
なんとなくオブジェクト指向っぽく、defclass的なものとmake-instance的なものとobj.field
的なアクセス記法を用意すればいけるかしら、という思惑で始めました。そして、まずは同じ意味論間でコードを吐けるようにするぞということで、現在mimiumのサンプルコードを同じ意味のコードに変換できる(つまり動作は変わらない)ようになりました。
mmmmの実装
見ればわかるのですが、Rust製です。Rustはわりと書きやすくて、言語のさまざまな機能がCのような落とし穴は極力エラーにするような方針で設計されているためゆるふわ勢でもエグいバグに悩まされなくてよく、そして型システムや所有権などのチェック機構によりコンパイルエラーを取ればデバッグはふるまいの確認のみに集中できる、というところが気にいっています。低レベルのプログラミングにも使えそうなところも魅力です。
mmmm言語は、現状はほぼ本家mimiumと同じですが、字句解析と構文解析にnomというRust製のパーサコンビネータを利用しています。
パーサコンビネータの勉強をしたいという動機もそういえばあったのでした。mmmmでは(同じ言語間の変換なので; つまりコードはASTをそのまま吐きだすだけなので)コードの比率的に現状パーサがほとんどを占めています。nomで基本的な枠組みをつくり、演算子の優先順位を決めるところだけ自前で操車場アルゴリズムを実装しています。nomというかパーサコンビネータは便利ですね。繰り返しや複雑な構文要素の組み合わせも基本的な関数の組み合わせで書けてしまい、書くぶんにはかなりすっきりしたコードになった気がします。ただコードがドキュメントみたいになってしまったので、意図通りの文法になっているかを保証する、あるいは意図した文法をBNFとかで明示する、とかしたほうがいいのかもしれません。
コード生成については特に言うことはありません。なぜならそのままだからです。
そんなに難しいことはやっていないので、初トランスパイラチャレンジなのを加味して2ヶ月くらいである程度うごかすところまで到達しました。
mmmmの今後
さて、実はこの節がメインです。
今後どうしようか、と悩んでいます。というのも言語の設計どうしたらいいかわからないからです。まず、オブジェクト指向的なものを入れてみるとして、構文的にあまり本家mimiumとバッティングしたくないなあという気持ちがあります。バッティングすると、いつかどちらかを削らないといけなくなり追従がむずかしくなりそうだなあというのがその理由です。第2に、そもそも「どうしたい」というモチベーション的な部分が弱かったので、自分がどうしたらいいかわからないのです。「オブジェクト指向的にすると実装は簡単そうだなあ」くらいの雑な動機で始めちゃった上に強く「こうしよう!!!」という芯がないので、mimium→mimiumコンパイルができた時点で道を見失いました。
そんなわけでさっそく寝かせている状態です。さてどうしたものか…。
書いていて気付いたんですが、よく考えたらmimiumでオリジナルのコードを書いたのはこのへん
mimiumでビート刻めた…!! ちょっとカッコよい。
— t-sin🥳 (@sin_clav) 2020年8月21日
というか最近画面キャプチャすると処理落ちみたいになるな…Ryzen7なのに…。 pic.twitter.com/VER9Zo7xzG
が最後な気がするので、もうちょっとmimiumに浸って「こうなってほしい!」点を蓄積するのがよいのかもしれないですね。