🦾

Ergの進捗・現状・これから

2022/12/07に公開

Python

本記事は言語実装アドベントカレンダー7日目の記事です。

Ergは本年、2022年8月に公開したプログラミング言語です。もしかしたらご存知で覚えている方もいるかもしれません。

そしてありがたいことに予想以上の反応と、何人もの方からのコントリビュートを頂きました。

Ergはその後も開発が続けられ、2022年12月現在、バージョン0.5.13(0.6.0ベータ公開)まで到達しました。
本記事ではこれまでの達成事項をまとめ、現状と今後の展望について記していきます。

開発記録

8月

8/10: GitHub上にて公開
8/12: v0.2.0公開、REPL機能を追加・Python組み込みAPIの呼び出しが一部可能に
8/28: v0.3.0公開、レコードを追加

9月

9/11: v0.4.0公開、クラスが安定化
9/14: Jupyter Notebook拡張を実装
9/22: v0.5.0公開、トレイト・ユーザー定義モジュールが安定化
9/24: Language Serverのv0.1.0を公開
9/25: Webサイトを公開
9/27: v0.5.4公開、d.er構文を追加、Pythonスクリプトが型付け可能に

10月

10/1: VSCode拡張機能を公開
10/15: v0.5.9公開、Dictを追加(全ての組み込みコンテナを実装)

11月

11/4: v0.5.11公開、Python 3.11に対応
11/19: Webプレイグラウンドを公開
11/25: v0.5.13公開、Pythonスクリプトへのトランスパイラを追加

12月

12/2: Patchを実装
12/5: 文字列補間を実装

現状

採用事例

流石にまだ私以外で実用を試みる人は確認していませんが、リアルワールドでの稼働例が多少あります。

このリポジトリではErgのドキュメントが管理されているのですが、GitHub ActionsでHTMLを書き換えるErgスクリプトが実行されています。セットアップにcargo/rustは使用されておらず、バイナリのダウンロードが行われています。このダウンロードスクリプトもErgで書かれています。

型検査器

まだ完成には何段階も足りませんが、主要なプリミティブ型は実装済みです。一段落したので不正な入力に対する耐性を向上させているフェーズです。

関数に対し不正な引数を与えた際の様子(コメントは手入力)

言語機能

TODOを確認したところ、82/133(62%)が実装済みのようです。TODO自体に記載されていない機能も無数にありますが、まあ半分程度は(一先ず動くものを)実装したと言って良いと思います。現在はパターンマッチ機能の完成を目下のゴールに据え、開発に取り組んでいます。

総評

総合的には、実際に使える言語にはまだまだ程遠いです。が、着実にそこへ向かっているとも考えています。今後の進展に是非ご注目ください。

今後の展望

ユーザー定義コンパイル時関数・多相型の追加

現在の主要なマイルストーンの一つが、ユーザー定義コンパイル時関数及び多相型の実装です。Ergではざっくり言って多相型=型を戻り値とする関数なので、前者の実装は後者の前提となります。これが完成すれば、主要な言語機能はほぼ全て揃うことになります。来年中には達成したいところです。

標準ライブラリの整備・主要なPythonライブラリの型付け

型宣言機能がぼちぼち安定化してきたので、NumPyやmatplotlibなど有名どころのPythonライブラリの型付けも行っていきます。また現状では型宣言したPythonのAPIは型検査を素通ししているのですが、これは健全ではないので(ユーザー定義の場合)実行時に検査させることも検討しています。
また根本的な解決策としてPython ASTをErg ASTに変換することも検討しています。これが実装されれば、実行時検査の数を大幅に削減することが出来ます。勿論、任意のPythonスクリプトの完全な静的型検査は原理的に不可能ですが、個人的体感では、世に溢れるPythonスクリプトの7~8割はErgの型検査器で検査・推論可能と考えています。

パッケージマネージャの実装

Ergで実際のアプリケーションを作るためには、パッケージマネージャの実装が必要不可欠と考えています。これはErg自体で実装する予定で、Ergの完成度を測る上でも重要なマイルストーンです。現在はそのための言語機能・モジュールの追加、および安定化も進めています。

バイナリを生成するバックエンドの開発

せっかく静的検査を行っているので、バイナリを生成できるようにしたいところです。

現時点で2つの案を考えています。一つはLLVM IRバックエンドで、コンパイラのバックエンドとしては最も手堅い選択肢です。

もう一つはRustバックエンド案です。これはErgスクリプトをRustのソースコードにトランスパイルしてしまうという案です。二重にコンパイルが行われるため効率は良くありませんが、こちらのオプションではRustのコード資産をスムーズに利用できるようになるという目算もあります。

因みに、アプリケーションがバイナリであることとPythonを呼び出せることは両立可能です。CPythonは他言語でモジュールを定義したりアプリケーションにインタープリタを埋め込んだりするためのAPIを用意しており、例えばRustにもPythonのバインディングライブラリが存在します。

セルフホスト

バイナリを生成するバックエンドが実装できたら、やはり目指すべきはセルフホストです。
正直ここまでいくにはもう何年かかかるでしょう(Zigはついこの前セルフホストコンパイラを公開しましたが、登場から実に7年以上かかっています)が、完成すればErgの実用性を示す強力な証拠となるでしょう。

Ergの実行に最適化されたVMの開発

これもまた雲を掴むような話ですが、Ergの静的検査を活用したCPython互換VMも開発したいところです。先述のAST変換器と組み合わせれば、ErgのみならずPythonも最適化の恩恵を受ける高速なバックエンドを実現出来るかもしれません。