Commits

camlspotter committed 4a1d991

update

Comments (0)

Files changed (1)

 
 2012年12月での関数型言語 OCaml コンパイラ一式をインストールした際に付属する「公式」ツール群の紹介を行う。多岐に渡るので、一つ一つの詳しい説明は行わない。各ツールの細かい情報はそれぞれのドキュメントを参照して欲しい。
 
-もし知らないツール名があったらちょっと読んでみて欲しい。もしかしたらあなたの問題を解決するツールがあるかもしれないから。(特に caml-types.el な。)
+もし知らないツール名があったらちょっと読んでみて欲しい。もしかしたらあなたの問題を解決するツールがあるかもしれないから。(特に caml-types.el)
 
 ★は重要度。五点満点。
 
 ==========================
 
 現時点での公式最新バージョンは 4.00.1。
-4.00.1 は基本的に 4.00.0 のバグフィクスリリース。4.00.0 では GADT と 3.12.1 より使い易い first class module が入っている。
+4.00.1 は基本的に 4.00.0 のバグフィクスリリース。
+4.00.0 では GADT と 3.12.1 より使い易い first class module が入っている。
 
 このところ OCaml のマイナーバージョンの変わるリリースは一年に一度位。
 バグフィックスパッチやリリースはより頻繁にある。
 OCaml 対話環境。いわゆる REPL(Read-Eval-and-Print Loop)。
 入力は型推論の後 bytecode へとコンパイルされ VM により評価される。
 Bytecode とはいえコンパイルが入るため、インタープリタとは普通呼ばれない。
-(Native code へとコンパイルする ocamlnat という対話環境も存在する。ただしまだ「非公式」)
+(Native code へとコンパイルする ocamlnat という対話環境も存在する。
+ただしまだ「非公式」)
 
-ocaml toplevel はラインエディタはない。行の編集や履歴を呼び出したい場合は、
+ocaml toplevel はラインエディタ機能はない。行の編集や履歴を呼び出したい場合は、
 
 * rlwrap : read line wrapper ( http://utopia.knoware.nl/~hlub/rlwrap/#rlwrap )
 * emacs の shell mode 内などでの実行
 で編集能力を強化するのが普通である。
 
 Real World OCaml programmer で toplevel を使うか使わないか…は人により違うようだ。
-Toplevel は値のプリンタがあるので、ライブラリをロードして関数のインタラクティブなテストを行う人がいる一方、私は全く使わない。
+Toplevel は値のプリンタがあるので、ライブラリをロードして関数のインタラクティブなテストを行う人はいる。
+一方、私は電卓として使うか型システムの挙動を確かめる時以外全く使わない。
 
 ocamlc bytecode compiler ★★★★★
 ---------------------------------------
 Native code コンパイルが可能な環境では通常このコンパイラを使う。
 
 OCaml コンパイラソースコードで make opt の後に make opt.opt を行うと作成される。
-通常の ocamlc, ocamlopt は bytecode で実行される。 
-\*.opt コンパイラは native にコンパイルされているため bytecode へとコンパイルされたコンパイラより実行速度が早い。
+通常の ocamlc, ocamlopt は bytecode で実行されるが、 
+\*.opt コンパイラは native にコンパイルされているため
+ocamlc, ocamlopt より実行速度が早い。
 (Bytecode 版コンパイラがひどく遅いわけではないが。)
 
-ocamlc, ocamlopt 以外のツールにも、.opt の postfix がついた native code バージョンが存在する。
+ocamlc, ocamlopt 以外のツールにも、.opt の postfix がついた 
+native code バージョンが存在する。
 
 依存抽出: ocamldep ★★★★★
 ==========================================
 ocamldep は複数の OCaml プログラムファイル間の依存関係を抽出するツール。
 結果は Makefile の依存書式で出力される。通常は、
 ocamldep \*.ml \*.mli > .depend
-として依存情報をファイルに書きだし、それを Makefile 等で include する。
+として依存情報をファイルに書きだし、それを Makefile 等で include .depend する。
 
-使い方の例は、 Makefile を使った OCaml ソフトウェアを見れば、まず使用されているので、それらを参考に。
+使い方の例は、 Makefile を使った OCaml ソフトウェアを見れば、
+まず使用されているので、それらを参考に。
 
 OCaml パーサーツール
 ================================
 
 ocamllex ★★★★
 ---------------------------
-Multi-byte char を処理する場合は、 ulex を使うべきである。
+**注意**: Multi-byte char を処理する場合は、 ulex を使うべきである。
 
-Lexical analyser。 Lex のスタイルを踏襲しつつ、アクション等のコードを OCaml プログラムで記述できる。
+Lexical analyser。 Lex のスタイルを踏襲しつつ、
+アクション等のコードを OCaml プログラムで記述できる。
 そのため、基本的に lexer (字句解析)や正規表現の知識が有用かつ前提。
 ocamllex は \*.mll というアクション等のコードを OCaml プログラムで記述できる。
 \*.mll の例は OCaml コンパイラソースの parsing/lexer.mll を参考にするといい。
 
 ocamlyacc ★★★★
 --------------------------
-ほとんど上位互換で、エラーメッセージの読みやすい Menhir を使うべきである。
+**注意**: 上位互換で、強力かつエラーメッセージの読みやすい Menhir を使うべきである。
 
 Parser generator。こちらは yacc のスタイルを踏襲し、アクション等のコードを OCaml プログラムで記述できる。
 そのため、 yacc の知識が必要。例えば shift-reduce, reduce-reduce の知識がなければ使いこなせない。
 ocamlyacc は \*.mly という拡張子のファイルを受け取り、 parsing rule を解釈し、 \*.ml へと変換する。
-注意すべき点は、 OCaml コード以外のパートでのコメントは (\* ... \*) ではなく、 /\* ... \*/ であることか。
+注意すべき点は、 OCaml コード以外のパートでのコメントは (\* ... \*) ではなく、 /\* ... \*/ であることくらいか。
 \*.mly の例は OCaml コンパイラソースの parsing/parser.mly を参考に。
+なおその場合は完全に shift-reduce 警告を 0 にしている所を味わうこと。
 
 ocamllex, ocamlyacc は色々と古臭い部分もあり、イライラすることもあるが、
-ほとんどアップデートもなく、非常に良く枯れているツールであるともいえる。
+ほとんどアップデートもなく、非常に良く枯れており高速に動作する。
+Lex-yacc も使えずに Parsec があーたらどーたらカッコイイとか構成的に書けるとか
+つぶやくのは甘えです。
 
-ocamlyacc のほぼ上位互換 parser generator として Menhir という外部ツールがある。 Menhir は ocamlyacc と同じ \*.mly ファイルを受け取る上に、エラーメッセージが読みやすいなど良い点が多い。そのため、現在 OCaml で parser generator を使う場合は Menhir を使うことが推奨されている。
-(ユーザに Menhir をインストールさせるのが面倒だと思われる場合は、 Menhir で新しい機能を使わず、デバッグ開発を行い、リリース時には ocamlyacc に戻す、ということも可能。)
+ocamlyacc のほぼ上位互換 parser generator として Menhir という外部ツールがある。 
+Menhir は ocamlyacc と同じ \*.mly ファイルを受け取る上に、エラーメッセージが読みやすいなど良い点が多い。そのため、現在 OCaml で parser generator を使う場合は Menhir を使うことが推奨されている。
+(ユーザに Menhir をインストールさせるのが面倒だと思われる場合は、 Menhir の新機能を使わず \*.mly を作り、リリース時には ocamlyacc に戻す、ということも可能。)
 
-lex-yacc は枯れている上に早い。Lex-yacc も使えずに Parsec があーたらどーたら言っているのは甘えです。
 
-マクロ/文法拡張システム: Camlp4 pre-processor and pretty printer ★★★
+マクロ/文法拡張システム: Camlp4 pre-processor and pretty printer ★★★
 =======================================================================
 Camlp4 (略称P4) は Pre-Processor and Pretty Printer の4つの P から P4 と呼ばれ、
 自分でパーサーをスクラッチから記述できるだけでなく、 
 OCaml コードでのマクロや文法拡張を実現することもできる強力なツール。
-P4 は yacc のような LALRベースではなく、 LLベースの stream parsing が使われるため、
+**P4 を使えるか使えないかで OCaml プログラマの生き死にが決まることもある**
+(と思わないとやっていられない時もある)。
+
+P4 は yacc のような LALRベースではなく、 
+LLベースの stream parsing が使われるため、
 ocamlyacc と camlp4 では文法記述法が異なる。
 
 P4 では OCaml の文法が stream parsing で再定義されており、
-このパーサーを使って OCaml プログラムを解釈し、その結果を OCaml コンパイラに送ることができる
+このパーサーを使って OCaml プログラムを解釈し、
+その結果を OCaml コンパイラに送ることができる
 (OCaml 標準の lex-yacc で書かれたパーサーは迂回される)。
 使い方は OCaml コンパイラの -pp オプションを見ること。
 
-この P4 の OCaml parsing rule群を動的に変更することで、 OCaml の文法を拡張することができ、
+この P4 の OCaml parsing rule群を **動的** に変更することで、 
+OCaml の文法を拡張することができ、
 単純なマクロから、非常に複雑なメタプログラミングまで P4 が活躍する。
 高レベルな OCaml プログラミングでは、P4 を利用した複数の文法拡張をしばしば利用するため、
 複雑ではあるが非常に重要なツールである。
 
 ocamlbuild は簡単な OCaml ソースに対しては ソースファイル名を列挙するだけでモジュール間の依存関係解析からコンパイル、リンクに至るまでを自動的に行なってくれる。そのため Makefile のような既存の外部ビルドシステムにおけるビルドの煩雑さから解放される。
 
-複雑なソース、プログラムコードの自動生成や特殊なリンクが必要な場合など、の場合は myocamlbuild.ml という OCaml モジュールで特殊ルールを実装することができる。myocamlbuild.ml では ocamlbuild が提供するルール記述のためのライブラリを使用することができる。問題はこのライブラリを使うドキュメントがあまり整備されていないこと。(Camlp4 3.10以降系といい、 ocamlbuild といい 3.10 周りで作られたツールはドキュメントが全くなっていない) また、ルール記述が OCaml という汎用言語で書かねばならないためどう見ても Makefile や OMakefile などのビルドに特化した言語に比べ煩雑に見えてしまうことである。もちろん OCaml の利点である型安全性やパターンマッチ、高階関数などによってビルドルールを構成的に書くことができるのだが…もう少し文法拡張などして DSL の風味を付け加えるべきではなかろうか。
+複雑なソース、プログラムコードの自動生成や特殊なリンクが必要な場合など、の場合は myocamlbuild.ml という OCaml モジュールで特殊ルールを記述し ocamlbuild に伝える必要がある。このファイルでは ocamlbuild が提供するルール記述用ライブラリを使うことができる。問題はこのライブラリを使うドキュメントがあまり整備されていないこと。(Camlp4 3.10以降系といい、 ocamlbuild といい 3.10 周りで作られたツールはドキュメントが全くなっていない) また、ルール記述が OCaml という汎用言語で書かねばならないためどう見ても Makefile や OMakefile などのビルドに特化した言語に比べ煩雑に見えてしまうことである。もちろん OCaml の利点である型安全性やパターンマッチ、高階関数などによってビルドルールを構成的に書くことができるのだが…もう少し文法拡張などして DSL の風味を付け加えるべきではなかろうか。
 
-私は ocamlbuild は使わない。OMake を使っている。とは言え、どうやら世の中的には ocamlbuild が標準になりつつあるのでそろそろ手を出さねばならない…
+私は ocamlbuild は使わない。現在のところ OMake を使っている。とは言え、どうやら世の中的には ocamlbuild が標準になりつつあるのでそろそろ手を出さねばならない…
 
-ドキュメントシステム: ocamldoc ★★
+ドキュメントシステム: ocamldoc ★★
 ======================================
 OCaml のコードを HTML や LaTeX の形に抽出するためのドキュメントシステム。
 ``(** ... *)`` という特殊なドキュメントコメントを使うことで簡単な整形記法や
 エディタ支援
 ==================================
 
-公式ソースコードに付属するエディタ支援は Emacs, XEmacs の物に限られる (Emacs24 動作未確認)
+公式ソースコードに付属するエディタ支援は Emacs, XEmacs の物に限られる
 ソースコードからビルドしている場合、 make install ではこれらの elisp ファイルはインストールされない。
 導入にはソースディレクトリ/emacs/README を読むこと。
 
 caml.el ★★★★★
 ------------------------
 OCaml プログラムのインデントとハイライトを提供する Caml-mode を提供する。
-外部ツールである tuareg-mode を好む人もいる。
+外部ツールである tuareg-mode を好む人(含む私)もいる。
 
 caml-types.el ★★★★★
 ----------------------------
 任意の部分式の型を表示させることで型エラー解消などの作業を効率的に行うためのツール。
 
-OCaml コンパイラ(ocamlc, ocamlopt)に -annot オプションを付けて \*.ml, \*.mli ファイルを
-コンパイルすると \*.annot というファイルができる。この \*.annot ファイルにはソースコード
-上の場所をキーとして、そこにある式の型などの情報が記録されいる。
+OCaml はその型推論のおかげでプログラム中に型を書く必要がほとんどない。そのため複雑なコードも簡潔に、かつ型安全に書くことができる。反面、型を明示的に書くことでプログラムが読みやすくなることもある。型が書かれていないため読みにくい他人の書いたコードや、型エラーが発生したがどうも何がおかしいのかわからない、といったことが起こり易くもなる。 caml-types.el を使えば OCaml コードの部分式の型を例えば明示されていなくともコンパイルの結果から表示させることができる。 **caml-types.el を使っているかいないかで OCaml プログラマの生産性は数倍変わるので生き死にに関係する。**
+
+OCaml コンパイラ(ocamlc, ocamlopt)に -annot オプションを付けて \*.ml, \*.mli ファイルをコンパイルすると \*.annot というファイルができる。この \*.annot ファイルにはソースコード上の場所をキーとして、そこにある式の型などの情報が記録されいる。
 caml-types.el はこのファイルを走査し、部分式の型を Emacs のメッセージバッファに表示する。
 
 caml-types.el は caml.el と独立しており、 tuareg-mode と一緒に使うこともできる。
 
-VIM ユーザは ocaml-annot ( https://github.com/avsm/ocaml-annot ) などを使っているようである。
-
-caml-debug.el ★★
-----------------------
-ocamldebug を Emacs で使うための elisp。現在実行中のソースコードの場所などを Emacs 中に表示できる。
+VIM ユーザは外部ツール ocaml-annot ( https://github.com/avsm/ocaml-annot ) などを使っているようである。
 
 ほとんど使用されないツール
 ====================================
 
-バイトコードデバッガ ocamldebug ★
+バイトコードデバッガ ocamldebug ★
 ------------------------------------------
 
 ごくたまに利用される程度である。
 
 ocamldebug では一旦進めたデバッグステップを巻き戻すことができるという、ちょっと変わった機能がある。とは言え… printf デバッグか、 gdb を使った native code プログラムのデバッグの方が判りやすい場合が多い。どうしてもプログラム挙動がわからない場合、念のために使われることが多い。これは ocamldebug が非力だからというのではなく、やはり静的に型付けされた関数型プログラムではキャストの誤りや NULL エラーが起こることがなく、あまりデバッグを必要としないから、というのが大きい。
 
+私は使わない…協調スレッドなどの実行順が判りにくいライブラリを使う場合デバッガではプログラムの実行を **人間** が追えないからだ。デバッガは追えていているのだが。
+
+caml-debug.el ★
+----------------------
+ocamldebug を Emacs で使うための elisp。
+現在実行中のソースコードの場所などを Emacs 中に表示できる。
+
 バイトコードプロファイラ ocamlprof と ocamlcp ★
 ---------------------------------------------------------
 
 ディレクトリ名がついている場合、それはインストールされないツールである。 OCaml をビルドするとその場所に実行ファイルができる。
 
 ./expunge
-    ライブラリ中のモジュールを外部から見えなくするためのツール。A というモジュールがライブラリにリンクされていれば、このライブラリを使うと外部から A という名前でこのモジュールにアクセスすることができる。 A を expunge すると、それができなくなる。
+    ライブラリ中のモジュールを外部から見えなくするためのツール。A というモジュールがライブラリにリンクされていれば、このライブラリを使うと外部から A という名前でこのモジュールにアクセスすることができる。 A を expunge すると、それができなくなる。コンパイラ屋さんくらいしか使わないツール。
 ocamlobjinfo
-    オブジェクトファイルやライブラリ \*.cm\* ファイルの環境依存情報を見ることができる
+    オブジェクトファイルやライブラリ \*.cm\* ファイルの環境依存情報を見ることができる。OCaml ではオブジェクトファイル間の整合性は md5sum で管理されているので \*.cmi の整合性が合わない!と言われ、これはコンパイラおかしいだろう!と感極まった場合に使うと良いかもしれない。
 tools/dumpobj
     \*.cmo ファイルをダンプして VM opcode を眺めることができる
 tools/read_cmt
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.