ディスカッション (9件)
独自のプログラミング言語を自作するという試みは、想像しているよりもはるかに手が届きやすいプロジェクトです。一方で、実用レベルまで持っていくには想像以上の難易度と技術的な深い洞察が求められます。言語設計という冒険の入り口に立ってみませんか?
もし自分でプログラミング言語を作るなら、Pythonにかなり似たものになると思うな。ほぼ100%そんな感じ。
記事の冒頭しか読んでないけど、libriscv0みたいなプロジェクトなら彼らのゲームプロジェクトにも使えたんじゃないかと思ってしまう。実はlibriscvの作者である伝説的なfwsgonzoもゲームを作ってるんだよね。Discordサーバーを覗いてみることを強くお勧めするよ。
何が言いたいかというと、libriscvは最速クラスのRISC-Vエミュレータだし、ゲームのサンドボックス用途にはC/C++/Luaなんかと組み合わせることもできたはずなんだ。
何か見落としてるかな?まあ、プログラミング言語を自作するっていうプロジェクト自体もすごくクールだけどね :-D
もしよかったら、libriscvについて著者がどう考えているのか聞いてみたい。個人的には要件をすべて満たしているように見えるからさ。
このプロジェクト面白いね。ただ、生のポインタ演算やC言語との相互運用性があるコンパイル言語で、どうやって「手軽なサンドボックス」という目標を達成するつもりなのか気になるところ。その点、著者の懸念はあるにせよ、Luaの方がよっぽどサンドボックス化しやすかったんじゃないかな。
(あと、ネイティブデータとLuaのデータ構造変換のオーバーヘッドを気にするなら、Luaのuserdataを調べてみるといいかも。結局のところ、LuaはCプログラムに組み込むために設計されてる言語だしね)
言語を自作するのは簡単だよ。難しいのは、車輪の再発明を強いることなく、実際に問題を解決できるライブラリを作ることだ。C++/Java/JavaScriptなどが生き残っているのには理由があって、それらの言語を取り巻く実績あるライブラリがあるからこそ成功してるんだよ。
自分もプログラミング言語作成のハードルの低さには驚いた口だけど、一般的な言語から入るのとは逆に、「ボトムアップ」で進めてみたよ。
チューリングマシンの記述と入力文字列を受け取って、ユニバーサルチューリングマシン[0]で実行可能なエンコード済みテープを出力するコンパイラツールチェーンとデバッガを書いたんだ。以前少し経験はあったけど、ここまで低レイヤーなコンパイラパイプラインを最初から最後まで作ったのは初めてだった。
最初は冗談半分で始めた実験だったけど、夢中になって設計することになるとは思わなかった:
- UTMを構築するための小さな低レイヤーASM
- シンボル幅とエンコーディング文法のためのABI
- 動作検証のためのインタプリタ
- ASM命令ごとの生のTM遷移(LLMに候補を出力させてはインタプリタで検証するループで生成した)
- 直接ASMからTMへの出力が手に負えなくなった時のためのCFG形式のIR(実際、LLMはかなりいい仕事をしてくれた。IRなしでここまでやるのは無理だったと思う)
- 生の遷移やASMルーチン、ブロックのためのGDB風デバッガ
- トレース可視化ツール
- L1のUTM/入力ペアをL2のUTMで実行するブートストラップ実験
- 最適化の実験
どのステップも自然で、他の要素と簡単に統合できた。一つひとつのステップは、その前のレイヤーを正しく動かすために必要な「局所的な修正」に過ぎなかったんだ。
[0] Repo: https://github.com/ouatu-ro/mtm (https://github.com/ouatu-ro/mtm)
似たようなものはたくさんあるけど、これは俺のやつ。 https://loonlang.com (https://loonlang.com)
自分もプログラミング言語を作るのをめちゃくちゃ楽しんでるよ[1]。自作言語でプログラムを書けるようになるまでって、意外と簡単なんだよね。
Sapphireっていう言語を作ってて、Rubyにインスパイアされてる。だから、どう動作させるか悩むときはRubyの内部構造を掘り下げるのが一番面白いところだな。
[1] https://github.com/sapphire-project/sapphire (https://github.com/sapphire-project/sapphire)
既存の言語のアイデアをコピーするだけなら、プログラミング言語を作るのは簡単だよ。
新しいアイデアをひねり出すのは難しい。特に、それを現実世界でテストしなきゃいけないんだからね。