ハクソク

世界を動かす技術を、日本語で。

Omプログラミング言語

89日前原文(om-language.com)

概要

  • Om言語 は、最大限にシンプルな 連結的・ホモイコニック なプログラミング言語
  • 3要素のみ （オペレータ・セパレータ・オペランド）から成る、最小限の構文
  • 型レス （パンモルフィック型）で、データ型を意識せずに記述可能
  • C++ライブラリ として実装され、拡張・埋め込みが容易
  • 開発初期段階 であり、実用には追加実装が必要

Om言語の特徴

  • 最大限にシンプルな連結型言語 ・ 要素数3 ：オペレータ、セパレータ、オペランドのみ構成 ・ ホモイコニック ：プログラム自身がデータ構造 ・ プレフィックス記法 ：関数は残りのプログラムを操作 ・ パンモルフィック型 ：データ型の宣言不要 ・ UTF-8完全対応 ：任意のUTF-8テキストが有効なOmプログラム ・ C++/Objective-C++組み込み ：ライブラリとして他プロジェクトに容易に統合可能 ・ 拡張性 ：新たなデータ型や演算子の追加が可能

Om言語の現状とライセンス

  • 未完成 ：現段階では概念実証（Proof of Concept） ・ 基本的な数値演算やファイル操作 などが未実装 ・ 最適化や機能追加 が今後の課題 ・ バージョン1.0まで大幅な変更 の可能性
  • Eclipse Public License v1.0 で公開 ・詳細はEclipse Public License FAQ参照

Omの利用方法

  • ソースコードの入手 ・ GitHubリポジトリ からクローンまたはアーカイブ取得 ・開発版はGit clone/アーカイブ、リリース版はタグページから取得
  • 利用形態 ・ スタンドアロンインタプリタ のビルド ・ C++ヘッダオンリーライブラリ としてプロジェクトに組み込み

ビルド・依存関係

  • ビルドに必要なプログラム ・CMake ・Mac OS X: Xcode ・Windows: Visual Studio, Cygwin（bash, GNU make, ar, ranlib含む） ・Ubuntu: build-essentialパッケージ（sudo apt-get install build-essential）
  • ドキュメント生成 ・Doxygen, Graphviz
  • 依存ライブラリ ・ICU4C（C++実装のICU） ・Boost

ビルド手順

  • ビルドプロジェクト生成 ・"[buildsディレクトリ]/Om/projects/[プロジェクト]"に生成 ・Unix系: "generate.sh"、Windows: "generate.bat"使用 ・プロジェクト名必須、CMake引数追加可 ・デフォルトで依存ライブラリ自動インストール（パス指定で既存ライブラリ利用可） ・例： -D Icu4cInstallDirectory:Path="[ICU4Cインストールパス]" -D BoostInstallDirectory:Path="[Boostインストールパス]"

インタプリタ・テスト・ドキュメント

  • Om.Interpreter ・"[Omビルドディレクトリ]/executables/[platform]/[configuration]/Om.Interpreter"としてビルド ・コマンドラインでUTF-8ロケール指定可能（デフォルト: "en_US.UTF-8"） ・標準入力から読み込み、標準出力へ逐次出力
  • Om.Test ・全ユニットテストを実行するテスト実行ファイル生成 ・ALL_BUILDターゲットでRUN_TESTSも実行
  • Om.Documentation ・"[Omビルドディレクトリ]/documentation"配下にHTML/XMLドキュメント生成 ・ブラウザでindex.htmlを開くことで閲覧可能

C++プロジェクトへの組み込み方法

  • "code"ディレクトリをインクルードパスに追加 ・必要なヘッダファイルをインクルード ・任意の操作ヘッダを追加すると自動でグローバルシステムに登録 ・"om.hpp"インクルードで全ヘッダ読み込み ・依存ライブラリへのリンク設定（build.cmake参照） ・Om::Language::System::Initialize関数を呼び出し、ロケール指定（例: "en_US.UTF-8"） ・Om::Language::Environment生成、必要な演算子マッピング追加、Evaluate関数でプログラム評価 ・詳細はソースコードドキュメント参照

言語構文

  • 3要素構成 ・ オペレータ ：演算子として機能 ・ セパレータ ：要素間区切り ・ オペランド ：データ値として扱う
  • オペレータ構文 ・バッククォート（`）が次に特定記号でなければ無視
  • セパレータ構文 ・要素間の区切り記号
  • オペランド構文 ・データ値を表現

関数・評価モデル

  • 連結型（concatenative） ・各プログラムが関数として評価 ・2つのプログラムの連結は、関数合成となる
  • プレフィックス記法 ・関数は残りのプログラム自体を操作 ・スタックアンダーフローが発生しない ・メモリ効率が高く、逐次評価が可能 ・イベント駆動や状態遷移も自然に記述可能 ・IDEで入力補完や型ヒント実現が容易

関数の種類

  • 恒等関数（Identity） ：入力プログラムの全要素を出力
  • 定数関数（Constant） ：指定要素＋入力全要素を出力
  • 演算関数（Operation） ：オペレータ名で定義、必要なオペランドを消費し、計算結果を出力 ・計算完了時は残りの入力も出力へ ・オペランド不足時はオペレータ自身と残り入力を出力へ

プログラムの評価規則

  • 空プログラム ：恒等関数として評価
  • 単一要素プログラム ・セパレータ：恒等関数 ・オペランド：定数関数 ・オペレータ：環境で定義された演算、未定義なら定数関数
  • 複数要素プログラム ・各要素をサブプログラムと見なし、連結は関数合成 ・例："A B"は "A"・"B"の関数合成 ・セパレータは恒等関数として無視

オペレーション・データ・型

  • 全データはオペランドで表現 ・伝統的なデータ型は存在しない
  • パンモルフィック型システム ・全データ値が共通の不変インターフェースを持つ ・全ての操作は任意のオペランドを受け取り、その内部プログラムでデータ処理 ・生成したオペランドも同様に次の操作で処理可能

実装の最適化

  • オペランドの内部実装は最適化可能 ・操作ごとに最適なプログラム実装を持つ ・例えば、セパレータを無視する操作では、要素のみを格納 ・操作は入力オペランドの実装タイプを判別し、最適な方法で処理 ・操作の順序を工夫し、変換コストを最小化可能

以上がOm言語の概要と導入、構文、評価モデル、実装最適化に関する要点です。

Hackerたちの意見

投稿で言及されている、もっと詳しい記事はこちら: https://evincarofautumn.blogspot.com/2012/02/why-concatenati...

└

あ、ありがとう！だから最初に思ったのは「これ、すごくFORTHっぽいな」ってことなんだよね。

これを https://github.com/omcljs/om と混同しちゃった。

└

そうだね、Omは数年前にすごく広く使われてたClojurescriptライブラリで、今でもそうだと思う。それがこの言葉の意味だと思ってる。

コード例を出さない言語については絶対文句言うわ。チャートやUI、スタイルライブラリを作っておいて、例を全然見せないってどういうこと？

└

例を見落としてるよ。それが満足できるかは別として、ちゃんと例はあるから。

└

もしそれが100%の確率でやってることなら、世界に本当に情報を追加してるのかな？

前の仕事でJason（Omのクリエイター）と一緒に働いたけど、彼はすごい人だよ！

どんなUTF-8テキスト（バイトオーダーマーカーなし）も有効なOmプログラムを定義します。マッチしないブレースを持つプログラムの挙動はどうなるの？ 余分な } が定義された構文に合うとは思えないけど。 https://www.om-language.com/index.html#language__syntax__

└

それは単一の演算子として解析され、次のルールで評価されるよ: > 環境内の演算子に対して定義された操作に評価される。もしそれがなければ、演算子とすべての入力項を出力プログラムにプッシュする定数関数に評価されると思う。単純に自分自身を出力するだけだと思うよ。

例の言語の構文は、もっと上の方に置いた方がいいと思うよ。サイトの半分までスクロールしないと構文が見れないのはちょっと辛かった。言語の雰囲気が分かるまでは、EBNF構文なんて誰も気にしないからね。