EOのオブジェクトモデルをeocで小さく試す
objectionary/eoは実運用向けに使える実用的なオープンソース実装で、再利用可能な導入ルートを持つプロジェクトです。
ひと目でわかる
- これは何？
- EOはφ-calculusを基礎に、型、クラス、可変性、null、通常の制御文を置かない実験的なオブジェクト指向言語です。
- 誰に向いている？
- 新しい言語モデルを小さなプログラムで検討したい人に向きます。まずJava SEとnpmを用意し、eolang@0.37.1でapp.eoをコンパイルしてdataizeまで通し、エラー表示、インデント規則、生成物を確認してください。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 1 日前です。
- 何の言語で書かれている？
- 主に Java です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月14日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
EO がオブジェクト指向から取り除くものとeoの確認
EO は phi 計算に基づく実験的な純粋オブジェクト指向言語です。README は冒頭で、Java、Ruby、C++、Python、C# などの人気のある半 OOP 言語は十分ではなく、Smalltalk、Eiffel、Self、Io でさえ作者が許容できないものを持っていると述べています。そのリストには、型、クラス、静的メソッドや属性、実装継承、可変性、NULL、グローバルスコープ、型キャスト、リフレクション、スカラー型やデータプリミティブ、アノテーション、演算子、トレイトやミックスイン、そして `for`、`while`、`if` などの制御フロー文が含まれます。各項目には反対理由を説明する記事へのリンクがあります。README には、EO がいつ実験段階を離れるのか、どのように本番で使われているのかは書かれていません。
eoについてREADMEが明記する範囲をこの節の中心にします。未記載の性能、可用性、セキュリティ効果は補わず、objectionary-eo-deep-analysisに固有の入力、設定、出力、ログを分けて確認します。
eoの確認記録1では、EOのREADMEは、app.eoにstdoutオブジェクトを結び、eoc --easy linkでコンパイルし、eoc --easy --alone dataize appで実行する流れを示します。インデントは意味を持ち、ネストには2つの空白を使います。通常のJavaやPythonの構文を前提にすると、設計思想と実際のエラーを取り違えます。 対象版と入力を記録し、objectionary-eo-deep-analysisに固有の出力差分を保存します。文書にない結果は未確認として扱います。
eoの実行メモ1では、最初の確認はHello worldだけで終えず、水平表記、括弧による引数のグループ化、抽象オブジェクトのコピーを別々に試すことです。Java SE、npm、eolang@0.37.1を固定し、生成されたtargetとコンパイル時間、失敗時の診断を保存します。実験的言語なので、既存コードの移植性や長期保守をREADMEから断定しません。 実行時刻、環境、終了コード、生成物の場所を対応付けます。結果が成功しても、READMEの記述を超える性能や安全性は主張しません。
hello world の実行例とeoの確認
クイックスタートでは、Java SE と npm をインストールしてから、`npm install -g eolang@0.37.1` で eoc をインストールします。最小のプログラムは `app.eo` ファイル内の `app` というオブジェクトで、その `@` 属性は `stdout` のコピーであり、引数として文字列 `"Hello, world!\n"` を受け取ります。`eoc --easy link` でコンパイルし、`eoc --easy --alone dataize app` で実行します。インデントは Python と同様に意味を持ちます。同じプログラムは角括弧で引数をグループ化する水平表記でも書けます。README が完全な実行例として示しているのはこの一つだけです。
EOのREADMEは、app.eoにstdoutオブジェクトを結び、eoc --easy linkでコンパイルし、eoc --easy --alone dataize appで実行する流れを示します。インデントは意味を持ち、ネストには2つの空白を使います。通常のJavaやPythonの構文を前提にすると、設計思想と実際のエラーを取り違えます。
最初の確認はHello worldだけで終えず、水平表記、括弧による引数のグループ化、抽象オブジェクトのコピーを別々に試すことです。Java SE、npm、eolang@0.37.1を固定し、生成されたtargetとコンパイル時間、失敗時の診断を保存します。実験的言語なので、既存コードの移植性や長期保守をREADMEから断定しません。
eoの確認記録2では、EOのREADMEは、app.eoにstdoutオブジェクトを結び、eoc --easy linkでコンパイルし、eoc --easy --alone dataize appで実行する流れを示します。インデントは意味を持ち、ネストには2つの空白を使います。通常のJavaやPythonの構文を前提にすると、設計思想と実際のエラーを取り違えます。 対象版と入力を記録し、objectionary-eo-deep-analysisに固有の出力差分を保存します。文書にない結果は未確認として扱います。
eoの実行メモ2では、最初の確認はHello worldだけで終えず、水平表記、括弧による引数のグループ化、抽象オブジェクトのコピーを別々に試すことです。Java SE、npm、eolang@0.37.1を固定し、生成されたtargetとコンパイル時間、失敗時の診断を保存します。実験的言語なので、既存コードの移植性や長期保守をREADMEから断定しません。 実行時刻、環境、終了コード、生成物の場所を対応付けます。結果が成功しても、READMEの記述を超える性能や安全性は主張しません。
抽象オブジェクト、コピー、デコレーションとeoの確認
EO プログラムは抽象オブジェクトから作られます。抽象オブジェクトは直接使えず、必要な引数を渡してコピーを作成しなければなりません。README は `stdout "Hello, world!"` のような単純なコピーと、フォーマット文字列とタプルを受け取る `printf` のより複雑なコピーを示しています。特別な属性 `@` はデコレーションを表し、オブジェクトが別のオブジェクトをデコレートすると、そのオブジェクトの属性がすべてデコレータに転送されるため、あたかもそのオブジェクトのように振る舞います。これは実装継承を置き換えます。README には `malloc.empty`、`seq`、`while`、`stdout` を使ったループの例もあり、小さな九九の表を出力します。制御フロー文は言語から取り除かれているため、この例はオブジェクトの組み合わせで反復を実現する方法を示しています。
eoの確認記録3では、EOのREADMEは、app.eoにstdoutオブジェクトを結び、eoc --easy linkでコンパイルし、eoc --easy --alone dataize appで実行する流れを示します。インデントは意味を持ち、ネストには2つの空白を使います。通常のJavaやPythonの構文を前提にすると、設計思想と実際のエラーを取り違えます。 対象版と入力を記録し、objectionary-eo-deep-analysisに固有の出力差分を保存します。文書にない結果は未確認として扱います。
eoの実行メモ3では、最初の確認はHello worldだけで終えず、水平表記、括弧による引数のグループ化、抽象オブジェクトのコピーを別々に試すことです。Java SE、npm、eolang@0.37.1を固定し、生成されたtargetとコンパイル時間、失敗時の診断を保存します。実験的言語なので、既存コードの移植性や長期保守をREADMEから断定しません。 実行時刻、環境、終了コード、生成物の場所を対応付けます。結果が成功しても、READMEの記述を超える性能や安全性は主張しません。
文法、XMIR、コンパイラパイプラインとeoの確認
文法は `eo-parser/PARSER_SPEC.md` で定義されており、仕様駆動で行ごとにすべての合法な形を分類し、番号付きの規則（`R-N.M`）をパーサ実装が直接参照します。参照パーサは `eo-parser/src/main/java/org/eolang/parser/` にあり、EO ソースを中間 AST なしで単一パスで XMIR に変換します。XMIR は XML の方言で、構文解析とコード生成の間の唯一の中間形式であり、XSD スキーマによって規定されています。すべての変換は、パース時の正規化とトランスパイル時のコード生成の両方で、ホスト言語で visitor パスを書くのではなく、XSLT 2.0 スタイルシートのパイプラインとして実装されています。README によると、これにより各中間状態を標準の XML ツールで検査でき、独立してテストできます。
eoの確認記録4では、EOのREADMEは、app.eoにstdoutオブジェクトを結び、eoc --easy linkでコンパイルし、eoc --easy --alone dataize appで実行する流れを示します。インデントは意味を持ち、ネストには2つの空白を使います。通常のJavaやPythonの構文を前提にすると、設計思想と実際のエラーを取り違えます。 対象版と入力を記録し、objectionary-eo-deep-analysisに固有の出力差分を保存します。文書にない結果は未確認として扱います。
eoの実行メモ4では、最初の確認はHello worldだけで終えず、水平表記、括弧による引数のグループ化、抽象オブジェクトのコピーを別々に試すことです。Java SE、npm、eolang@0.37.1を固定し、生成されたtargetとコンパイル時間、失敗時の診断を保存します。実験的言語なので、既存コードの移植性や長期保守をREADMEから断定しません。 実行時刻、環境、終了コード、生成物の場所を対応付けます。結果が成功しても、READMEの記述を超える性能や安全性は主張しません。
ビルド統合とベンチマークとeoの確認
EO は `eo-maven-plugin` を通じて Maven ライフサイクルの一部としてコンパイルされます。`parse`、`assemble`、`transpile` などの mojo が `generate-sources` と `process-sources` フェーズで実行されます。外部の EO オブジェクトは、バイナリアーティファクトリポジトリではなく、Git でホストされた正規オブジェクトのレジストリである Objectionary から解決されます。`MjPull` mojo はビルド時に不足している `.eo` ソースを取得してローカルにキャッシュします。標準ライブラリは EO 自身で書かれており、`eo-runtime/src/main/eo/` にあります。README には `mvn install` の実行時の XSL スタイルシートの時間のベンチマークが含まれています: `to-java.xsl` は 54412 ミリ秒、合計は 158017 ミリ秒で、2026-05-08 の GitHub Actions ジョブ、4 CPU の Linux で測定されました。このベンチマークはスタイルシートのコストだけを対象としており、プログラム全体の実行性能は測定していません。
eoの確認記録5では、EOのREADMEは、app.eoにstdoutオブジェクトを結び、eoc --easy linkでコンパイルし、eoc --easy --alone dataize appで実行する流れを示します。インデントは意味を持ち、ネストには2つの空白を使います。通常のJavaやPythonの構文を前提にすると、設計思想と実際のエラーを取り違えます。 対象版と入力を記録し、objectionary-eo-deep-analysisに固有の出力差分を保存します。文書にない結果は未確認として扱います。
eoの実行メモ5では、最初の確認はHello worldだけで終えず、水平表記、括弧による引数のグループ化、抽象オブジェクトのコピーを別々に試すことです。Java SE、npm、eolang@0.37.1を固定し、生成されたtargetとコンパイル時間、失敗時の診断を保存します。実験的言語なので、既存コードの移植性や長期保守をREADMEから断定しません。 実行時刻、環境、終了コード、生成物の場所を対応付けます。結果が成功しても、READMEの記述を超える性能や安全性は主張しません。
貢献方法と README が明らかにしていない点とeoの確認
貢献は `master` ブランチへのプルリクエストです。README は `mvn clean install -Pqulice` を実行するよう求めており、これには Maven 3.3+ と Java 21+ が必要です。そのプロファイルなしのビルドには Java 17+ が必要です。ブランチ名は issue 番号に合わせ、コミットメッセージは `fix(#42):` で始め、プルリクエストは追加と削除を合わせて 40 から 100 行に保ち、大きな変更は PDD で分割するように求めています。README にはライセンス文が含まれていません。リポジトリのメタデータは MIT を示していますが、ライセンスのテキストがないため、保証やサポートについてライセンスが何を認めるかを述べることはできません。また、セキュリティポリシー、行動規範、安定したリリースプロセスがあるかどうかも書かれていません。
eoの確認記録6では、EOのREADMEは、app.eoにstdoutオブジェクトを結び、eoc --easy linkでコンパイルし、eoc --easy --alone dataize appで実行する流れを示します。インデントは意味を持ち、ネストには2つの空白を使います。通常のJavaやPythonの構文を前提にすると、設計思想と実際のエラーを取り違えます。 対象版と入力を記録し、objectionary-eo-deep-analysisに固有の出力差分を保存します。文書にない結果は未確認として扱います。
eoの実行メモ6では、最初の確認はHello worldだけで終えず、水平表記、括弧による引数のグループ化、抽象オブジェクトのコピーを別々に試すことです。Java SE、npm、eolang@0.37.1を固定し、生成されたtargetとコンパイル時間、失敗時の診断を保存します。実験的言語なので、既存コードの移植性や長期保守をREADMEから断定しません。 実行時刻、環境、終了コード、生成物の場所を対応付けます。結果が成功しても、READMEの記述を超える性能や安全性は主張しません。
編集部の結論
新しい言語モデルを小さなプログラムで検討したい人に向きます。まずJava SEとnpmを用意し、eolang@0.37.1でapp.eoをコンパイルしてdataizeまで通し、エラー表示、インデント規則、生成物を確認してください。
コミュニティノート