Field Reportsの特徴 (2)

前回の続きです。

OCamlで帳票ツールを作ってみてどうだったのか？

OCamlの生産性の話や構文の話は既にあちこちで語られていますので，「LL言語の拡張ライブラリをOCamlで記述する」という特殊な用途で使用した中で感じたことを書いてみたいと思います。

項目の数で見ると否定的な感想が多いですが，全般的にはOCamlを使用するという選択は正解だったと考えています。

Cオブジェクトを出力できる

今回の用途では，この機能に一番魅力を感じました。
今までC/C++でしか作れないと考えられていたものが，生産性の高い関数型言語で作れるというのは画期的です。C/C++向きと考えられていたシステム寄りプログラミングの分野にも食い込んでいけるのではないでしょうか？動作速度も十分速いし，信頼性の高いプログラムを作りやすいですし。
ただ，そのためにはライブラリをかなり充実させる必要がありますが…。

OCamlライブラリのバイナリ配布が難しい

せっかくなので，OCamlライブラリ(*.cma/*.cmxa)の形態でも配布しようと計画していたのですが，具体的な方法を考えていくと，色々と問題が出てきました。

まず，インストール先で依存しているライブラリ（しかも同じバージョン）をすべてインストールしてもらうのは現実的ではありません。そこで，依存しているライブラリをすべてまとめたライブラリを作ろうと考えたのですが，簡単ではないようです。-pack オプションでオブジェクトをまとめられるという情報を頂きましたが，標準ライブラリを含めてすべて -for-pack オプションを付けてビルドし直すのは大変そうなので躊躇しています。

次に，-pack オプション等でオブジェクトをまとめられたとして，OCamlの異バージョン間でのオブジェクト形式の互換性がどこまであるのか不明です。以前ちょっと検索した限りでは，バージョン間の互換性がないような記述を見かけたので。

そこで考え方を変えて，LL言語用に作成した共有ライブラリをOCamlのC言語インターフェースを通して呼ぶという方法も実験してみました。
結果としては，バイトコードからの呼び出しは成功しましたが，ネイティブコードからの呼び出しは失敗でした（コアダンプしたり，何もせずに終了したり）。きっと，内部的に管理しているデータか何かがバッティングしているんでしょう。

そんなわけで，OCamlライブラリのバイナリ配布は目処が立っていません。
OCaml同士では，ソース配布しか考えられていないようですね。

デバッグ手法は模索中

デバッガは使っていません（使いこなせていません）。
デバッガを使わなくても，トップレベルから #use で開発中のソースを取り込んでから手動で関数を実行できるので，それほど不便を感じません。

ただ，モジュールの構成が複雑になってくると，手動で呼び出すのがだんだん難しくなってくるので（モジュールの中身がトップレベルに展開されてしまうため），次第にデバッグ出力中心になってきました。

今書いていて気がついたのですが，module宣言をきちんとソースに書いておけば，#use で取り込んでもモジュールの再定義ができたのかなあ？

ビルドシステムに何を使うか迷う

ocamlbuildとかOCamlMakefileとかOMakeとか色々あって，何を使えば良いのか迷いました。結局OMakeを選びましたが，途中で何度も挫折しそうになりました。入門者の立場から言えば，なんでも良いので「定番」が確立していれば，迷わず取り組めたと思うのですが。