DEV Community: SUZUKI Tetsuya

OCaml の記号あれこれ

SUZUKI Tetsuya — Thu, 23 Jan 2020 16:29:20 +0000

※この記事は 2014年03月23日に Qiita に投稿したものです。

※ちょっと見出しと構成の一部を変えました。

おはようございます。今日も一日、よろしくお願いします。

大事なことなので二度コピペしました。おはようございます、 OCaml ビギナーです。先日、私のコードの diff を眺めていた CVO（最高美夢責任者）が

「くっ、我がダークヴィムマスターの戦闘力を以てしても皆目検討が付かぬ……これが神の創りし大駱駝（※ OCaml のことらしい）の力……」

とつぶやかれておりましたので、

「っふ……駱眼（※ OCaml のコードを見抜く第三の目。慈悲はない）を持たぬ者にはわからんだろう……ククク、俺の右眼が疼くわ！（花粉の季節はつらいです）」

と突き放しておきましたが、はて具体的に何がわからなかったのか聞きそびれました。ところで私は、 OCaml の実用的なコードに含まれる見慣れない記号の多さに面食らった覚えがあります。最近になってやっとだいたいの記号の意味がつかめてきましたので、メモしておきます。

以下、並び順は適当な個人的指標です。 実際の遭遇傾向とまったく関係ない のであしからず。 # で始まるサンプルコードは ocaml （トップレベル対話環境）の入力です。

レアリティ：N

`(* ... *)` `(** ... *)`

コメントです。アスタリスク二つで始まるコメント (** ... *) は Ocamldoc で抽出できるらしいです。例えばこんな感じ（たいした意味もなく Real World OCaml より抜粋）:

(** Bump the frequency count for the given string. *)
val touch : (string * int) list -> string -> (string * int) list

`[ ... ]`

リスト（list 型）を生成します。要素の区切り文字には ; を使います。

例:

# let words = ["foo"; "bar"; "baz"];;
val words : string list = ["foo"; "bar"; "baz"]

配列やリストの要素の区切りが , である言語に慣れていると、思わぬタイミングではまることがあるので要注意です。

`,`

タプルを生成します。ただし、タプルの型は各要素を * で区切って表します。型の定義と値の生成とで使う記号が異なるので、私はしばらくの間ときどき間違えました。

(* 型の定義 *)
type name = string * string

(* タプルの生成 *)
let johndoe = ("John", "Doe")

(* パターンマッチ *)
match s with
| (first, last) -> Printf.printf "my name is %s %s" first last

`;`

文の区切りです。と言っても OCaml の文法の大半はこの区切りが不要なので、コードの短い関数ではあまり使いません。すでに上で触れているように、リスト（以下）やレコードの要素を区切るのにもこの記号を使います。

しかし、なぜ区切り記号が ; だったり , だったりするのか？これには一貫性があるらしいですよ。なるほど、そう言われるとそうですね。

`&&`

論理積（AND）の演算子です。まあ想像つきますよね。 and もありますが、こちらは別の目的で使われる文法です。

`||`

論理和（OR）の演算子です。 or も予約語に含まれていますが、現在は deprecated です。

`::`

リストを合成する演算子です。 x :: xs で xs の先頭に x を追加したリストを生成します。

`'`

シングルクオートは識別子に使えます。 x' と言う変数名も、 f' と言う関数名も OK です。

ですが、 'a の形の変数は定義できません。これは型変数と言って（Web で検索！）、型の表記に使われます。

`|`

バリアント型とパターンマッチで、複数のパターンを区切って書くのに使います。これはコードを見るのが早いですね（どれもか）。

(* バリアント型の定義 *)
type foobar =
    Foo (* | Foo としてもよい *)
  | Bar
  | Baz

(* パターンマッチ *)
match v with
| Foo -> ...
| Bar -> ...
| Baz -> ...

`->`

パターンマッチのガードまたは型の表記に使われます。例えば、文字列の特定の位置の文字を取得する関数 String.get の型は string -> int -> char です。

(* パターンマッチ *)
match v with
| Foo -> ...
| Bar -> ...
| Baz -> ...

`()`

括弧の間には何も入りません。これは unit 型と呼ばれる何も持たないタプルで……他の言語で言う void ですね。

引数に () を指定している関数を見つけたら、それは特に引数を必要としない関数です。関数は何かしら引数をつけないと呼び出せないので、型が unit -> で始まる関数は () を指定すれば呼び出せます。例えばこんなの:

# Sys.getcwd ();; (* カレントディレクトリを取得する *)
- : string = "/Volumes/Users/szktty"

エントリポイントの let () = ... もこの記号ですね。こちらは引数ではなくパターンマッチですけど。

`^`

文字列を連結する演算子です。 OCaml の文字列は可変ですが、拡張はできません。この演算子を使うと新しい文字列が生成されるので、連結の繰り返しには Buffer を使いましょう（これを書いているヤツは、ここに来て「アッ、俺がコピペしてた Buffer はこれだったのか！」と気づいた）。

`+.` `-.` `*.` `/.`

浮動小数点数同士を加算する演算子です。 OCaml では多重定義が禁止されているので〜と言った理屈はともかく、整数には整数同士の、浮動小数点数には浮動小数点数同士の演算子を使わなければならないため、 1 + 0.1 とか 1.5 + 3.2 のような式は書けません。

`_`

識別子に使える記号です。パターンマッチではワイルドカードと呼ばれますが、実は他の変数と比べて特殊な働きをするわけではありません。 _ としても v としても、任意の値にマッチします:

match exp with
| 0 -> ...
| v -> ... (* 0 以外の値にマッチする *)

ただし、この記号を変数名（または関数名）の先頭につけると、その変数はある警告をすり抜けます。通常は定義した変数をまったく使わないと未使用の変数としてコンパイラに警告されますが、そのチェックが行われません。つい let _ = と書かないように気をつけましょう。

match exp with
| 0 -> 0
| v -> 1 (* v を使っていないため、未使用の変数として警告される *)

match exp with
| 0 -> 0
| _ -> 1 (* "_" に対しては警告されない *)

もう一つ、これは別段言語仕様でも強制でもありませんが、命名の慣習として識別子（特にレコードのフィールド名）の最後に _ をつける場合があります。よく見る/やるのは end_ や to_ ですね。理由は単純で、同名の予約語 end to があるからです。頭ひねって別名考えても回りくどいだけだし、二文字三文字の単語を省略するとわかりにくいし、それじゃあお尻に _ をくっつけとけば……良心が疼くほどでもないっしょ？

type location = {
  start : int;
  end_ : int;
}

レアリティ：R

`[| ... |]`

配列（array 型）を生成する文法です。これで [...] との区別は完璧ですね！

# [|1; 2; 3|];;
- : int array = [|1; 2; 3|]

`:=` `<-`

OCaml にも破壊的代入ってやつがあります。ただしどの変数でもと言うわけにはいかず、 ref キーワードを指定した変数か、 mutable キーワードを指定した（レコードの）フィールドに限られます。前者と後者で記号がなぜだか異なりますが、見りゃわかると思うのでもう何も怖くない！

`=` `<>` `==` `!=`

等値演算子です。 Jane Street Core ライブラリを使っている場合、 == か != を使うと次のエラーメッセージが表示されます。

Error: This expression has type int but an expression was expected of type
               [ `Consider_using_phys_equal ]

なんのこっちゃ？と思っていたのですが、 OCaml では == と != はポインタ同士を比較する演算子です。ですから、私のように文字列を == で比較してしまうと想定外の結果ではまります（これは Jane Street Core を使っていなくても同じです）。こればかりはコンパイラもバグかどうか判別できません。

(* true にならない！ *)
# "a" == "a";;
- : bool = false

あなたが求めている演算子は = と <> ですね。異論は認めない。恥辱に塗れた己の黒歴史と共に == と != を封印してドヤリングするのです（誰に

`~`

ラベル付き引数で使われる記号です。ラベル付き引数は使おうが使うまいがあなたの好きにすればいい機能ですが、お前のラベル定義なんざ無視してもコンパイルが通ります（そう、デフォルトの警告設定ならね）。何が言いたいのかって……面倒臭いのでリンク先を読んでください。それも面倒臭ければ -warn-error L を指定しとけば損しないです。

ちなみに私もつい最近まで警告オプションを設定していなかったため、 API リファレンスにラベルが書いてあっても理解を後回しにして（=調べるのをさぼって）引数を指定していました。もし私が OCaml のエラい人とペアプロでもしようものなら、「うわっ…君の年収、低すぎ…」と蔑みの視線が向けられること確実です（俺の年収は関係ねえだろ！）。

`?`

オプショナル引数=省略できるラベル付き引数で使われる記号です。 OCaml では関数に定義より少ない引数を与えると部分適用として扱われるため、オプショナル引数の使い方に注意が必要です。

私は引数を省略できると知って、さっそく引数いらずの関数を定義しようとしたのですが、

(* 警告されつつもコンパイルは通るけれど…… *)
# let test ?(x=0) = x;;
Warning 16: this optional argument cannot be erased.
val test : ?x:int -> int = <fun>

何やら警告が出ます。しかし、たかが初見の警告程度で怯む私ではありません。 OCaml ビギナーの考える引数いらずの関数呼び出しとは……これだっ！

(* 引数がなければ呼び出せません *)
# test;;
- : ?x:int -> int = <fun>

……ですよねー。うーん、じゃあこうかなとやってみる俺、さすがビギナーです。目のつけどころが違う。

(* ダメなものはダメです。型が違うだろ！ *)
# test ();;
Error: The function applied to this argument has type ?x:int -> int
This argument cannot be applied without label

むむむ……仕方がない、妥協して引数を与えてやろう。これはどうだ？

(* ラベルなし引数を与えるとエラー *)
# test 0;;
Error: The function applied to this argument has type ?x:int -> int
This argument cannot be applied without label

うっ……結局、ラベルを指定すれば呼べました。でも、もはや引数省略の意味がないですね。

(* オプショナル引数とは何だったのか *)
# test ~x:0;;
- : int = 0

どうしてこうなるのかと言えば、 OCaml では関数を呼び出すのに必ず引数が必要だからです。前述の test () は C などのメジャーな言語にある test() の () 的な呼び出しベルではなくて、 () という unit 型の値を引数として渡す式として解釈されます。すっかり身に付いてしまった手癖で引数ゼロとしたつもりが、実は引数を一つ与えていたんですね。

さて、オプショナル引数にはもう一つ注意すべき点があります。ご期待通り私はまんまとトラップに引っかかってしまうのですが……（まあこれが、知ったかぶりで走り出す私のビギナーたる所以です）最後の引数をオプショナル引数にはできません。やってみると、

(* 同じ警告が出る *)
# let test y ?(x=0) = x + y;;
Warning 16: this optional argument cannot be erased.
val test : int -> ?x:int -> int = <fun>

先程と同じ警告が出ます。そうなるとやはり、

(* これじゃだめ *)
# test 1;;
- : ?x:int -> int = <fun>

(* ラベルを指定すれば OK 、だけど…… *)
# test ~x:1 2;;
- : int = 3

ビギナーの思うようには動きません。オプショナル引数は最後から二番目までに定義しましょう。暇を見つけて「部分適用」をヒントに考えてみると、あなたの OCaml レベルキャップを引き上げられるかもしれません。

# let test ?(x=1) y = x + y;;
val test : ?x:int -> int -> int = <fun>
# test 2;;
- : int = 3

まあ実は、どちらのミスもコンパイラオプションの -warn-error に 16 か X を指定しておけば防げるんですけどね。デフォルトでオンにしてくれてもよさそうですけどね。

レアリティ：SR

`

多相バリアントを示す記号です。多相バリアントにはこの他にも [> や [< の記号があって、一見するとまあわけがわからないので後回しにしたくなりますね。

でもこれ、早めに理解しておくとよさそうです。それまで私はバリアント型を定義するのにどうも身構えてしまって戻り値に bool を使いがちでしたが、多相バリアントなら気楽にわかりやすい戻り値を使えますしね。

`@@`

4.01.0 から導入された演算子で、貴様の眼に映るすべての括弧を吹き飛ばす暗黒 OCa……まあ、 Haskell で言うアレ（$）です。たびたび使うので、レアな記号でもないんですけど。

さてビギナーの私は、「おお括弧を省ける」と喜び勇んでこう書いてみたわけですよ。みんな一度はやるよね？あれ、やらない？

`
(* 括弧を省け……ない……だと……？ *)

Some @@ x + y;;

Error: The constructor Some expects 1 argument(s),
but is applied here to 0 argument(s)
`

Some は option 型のコンストラクタなんですが、 OCaml ではコンストラクタは関数ではないため @@ が使えません。この場合は横着せずに Some (x + y) と書くほかありません。

ちなみに、私はたまに @ と間違えて型エラーを指摘されます。二文字打つのも面倒くさいし、& を用意しようかな。

`|>`

@@ の逆を行く演算子です。例えば x と y を足すだけの単純な関数 test があったとして、

let test x y = x + y;;

val test : int -> int -> int =
`

@@ を使うとこう書けます。

test 1 @@ 2 + 3;;

: int = 6 `

|> を使うとこう書けます。

2 + 3 |> test 1;;

: int = 6 `

@@ はわかったけど、 |> はどういうときに使えばいいのかって？え……ビギナーの私にそれを聞きますか。あなたの実際書くコードから無限デジャブめいたエイジングスメルが漂い始めたら考えればいいんじゃないですか？私も本気出した暁には考えます。

レアリティ：SSR

`;;`

私も ocaml トップレベルは使わないのでよーけ知らんで。

`@`

この記号を絶対に夜一人で見てはいけない……。いいか、絶対にだ！

OCaml の警告オプション（の一部）

SUZUKI Tetsuya — Thu, 23 Jan 2020 16:19:39 +0000

※この記事は 2014年05月05日に Qiita に投稿したものです。

警告、してますか？

こんにちは、 OCaml タグの投稿が少ないのをいいことに好き勝手書いてる OCaml ビギナーです。私しか OCaml 書く人がいないんで、仕事でも好き勝手書いてます。書く人がいなければなかなかレビューを受ける機会もないので、独り言が増えました。ぼっちレビューです。

「ちょっとアンタ、ナニよこれ？関数名もコンストラクタ名も CamelCase で書いてあるじゃない！関数名は snake_case 、コンストラクタ名は先頭大文字の Snake_case に直しなさいヨ！」
「イヤァヨ、そんなのキモいじゃない。モジュールとコンストラクタで先頭を大文字にすんなら、ぜーんぶ CamelCase で揃えるのがモプ、すなわちモダン・プログラマーなのヨォ。あらヤダ、これって駱駝っぽくてカッコよくなくない？」
「このバカチン！修正コミットしたらガイドラインを百遍音読しておきなさいヨ！（日本語訳はココヨ！）」
「ナニサ、アンタたちだってぶれっぶれじゃないの。モジュール名を原則 Snake_case にしてたり、コンストラクタ名を CamelCase で通す人も見たわヨォ。やぁねェ、いい歳してカビ臭いガイドラインで束縛したがる男って。 30 インチのワイドディスプレイがデフォルトの時代に 80 カラム幅って何？アンタら加齢臭がキツイのヨッ！」
「ダマらっしゃい、ミドル脂臭風情がッ！アンタみたいなペーペーはね、十年ゲザってアタシのありがたーいアドバイスを聞いてりゃいいのヨ！だいたいアンタはねェ……あらまァ、この open の羅列はナニ？これじゃどこの馬の骨に依存してんだかわかりゃしない。いい加減に警告オプションを指定おしッ！すべての open を駆逐ヨッ！」
「ハイハイ、ワカリマシタ……アァーン、警告ちゃんったら 45 もあるじゃないのォ。ンもぉメンドくさくなっちゃったわアタシぃ。こうなったらゼンブ無視よ無視」
「マッタク、最近の若いコときたら！先人の血と汗とヒゲを何だと思ってるのかしら。ブツブツ……」

アッハイ、余計な前説にカマってないで先を進めます。バージョン 4.01 で利用できる警告の数は 45 + アルファベットの数だけあります（アルファベットは数字の別名またはグループ化です）。 45 も警告があると調べるのがしんどくて、個人的に気になったやつを調べるだけで力尽きました。

【すべてのエラーを】警告 A【消し去りたい】

すべての警告を有効にします。

……

はい死んだ！今君のソースコード死んだよ！「とりあえず全部エラーにしとけ」と思って -warn-error A ってやっただろ！ずらずら出てきた警告を潰そうとして手をつけたのはいいが、メッセージの意味がわかんなくて直しきれないんだろ！ビルドできなくなっちゃっただろ！あぁん？怒ってないから正直に言ってみろ！

ハァハァ……き、貴様のようなビギナーはすべての警告を有効にしつつ、そこから厳し過ぎてコーディングがしんどいものを除くのが吉です。

警告に関するオプションは -w　と -warn-error があります。オプション引数には有効にしたい警告のリストを指定するのですが…… -w のフォーマットが少し風変わりでして、任意の警告番号の範囲をまとめて有効化/無効化したり、 -warn-error を使わずに警告をエラー扱いにできます。詳しい解説書なら事細かに説明するところかもしれ……しないか。ただ、お前らビギナーはしちめんどくさいフォーマットを覚える必要はなく、消去法で警告を指定するやり方のみ知っておけばいいと思います。フォーマットはこうです。

-w A-?-?-... -warn-error A

無効にしたい警告を - で区切ります（- は警告を無効にする指示子です）。例えば、私は次のオプションを指定しています。まあ、ほぼ受け売りなんですけど（い、一応自分でも調べて選んだんだからねっ！）。

-w A-4-9-40-42-44-45 -warn-error A

このオプションは 4, 9, 40, 42, 44, 45 を除くすべての警告を有効にし、かつエラーにします。これに 6 を加える場合もあるようですが、プロジェクトに応じて判断してください。

ちなみに、デフォルトの警告設定はこうです。

-w +a-4-6-7-9-27-29-32..39-41..42-44-45

すべての警告から 4, 6, 7, 9, 27, 29, 32 から 39, 41 から 42, 44, 45 を除くもの、つまり 1, 2, 3, 5, 8, 10 から 26, 30 から 31, 40, 43 がデフォルトで有効です。何言ってんだかわからないと思いますが、デフォルトの設定では結構適当なコードが書けちゃいます。

ちなみに、 Real World OCaml のコードのコンパイルに使われている警告設定はこうです（"Compiler Warnings" のところ）。あくまで本のための警告設定ですから、実務でもこれでいいのかは知りません。

-w @A-4-33-41-42-43-34-44

【ワイルドカード】警告 4 または E【禁止令】

バリアント型に後からコンストラクタが追加されても成立するパターンマッチに対して警告します、とあります。早い話が、ワイルドカードを使った手抜きのパターンマッチを見つけるとぶん殴りに来るようです。（ドキュメントではこういうパターンマッチを "fragile pattern matching" と呼んでいるようですが……どこかで定義されているのかな？）

例:

type t =
  | A
  | B
  | C

let is_a t =
  match t with
  | A -> true
  | _ -> false

コンパイル結果:

File "e.ml", line 7, characters 2-47:
Warning 4: this pattern-matching is fragile.
It will remain exhaustive when constructors are added to type t.

関数 is_a のパターンマッチでは、 A 以外のコンストラクタをワイルドカードで無視しています。例えばコードを書き進めるうちに t 型には D も必要だったとわかったとします。

type t =
  | A
  | B
  | C
  | D

このように書き足したとしても、 is_a を変更する必要はないですね。ワイルドカードで無視しちゃうんで。この警告を有効にすると、ワイルドカードを使わずにこのように書かないといけません。

let is_a t =
  match t with
  | A -> true
  | B -> false
  | C -> false
  | D -> false

逐一こう書くようにすれば、後から追加したコンストラクタがワイルドカードによっていい加減に扱われることで発生するバグを防げそうです。しかし反比例してタイプ量が相当増えます。めんどくさいですね。めんどくさいですが、とてつもなく厳密なコーディングが要求されるような大人数参加のプロジェクトでは有用なのかもしれません（そうは言っても、パターンマッチを適当に実装されれば無駄ですが）。でもやっぱりあまりにもめんどくさいんで、私は無効にしてます。

ところで、 Menhir（OCaml 用の yacc）を使う場合には注意が必要です。 Menhir がこの警告に引っかかるコードを生成するので、 -warn-error でこの警告をエラー扱いにするとビルドが止まってしまいます。それもあって、私は無効にしてます。

【ラベル嫌いを】警告 6 または L【誅したい】

この警告を有効にすると、ラベル付き引数に対してラベルなしの引数を与えた場合に警告されます。例によって適当な例:

# let test ~x y = x * y;;
val test : x:int -> int -> int = <fun>
# test 1 2;;
Warning 6: labels were omitted in the application of this function.
- : int = 2

デフォルトではこの警告は無効にされており、警告 A を指定してもこの警告を外す人もいます。なんでしょうね、この避けられっぷりは。古参の OCaml ユーザーにはラベルが体に馴染まない方が多いんでしょうか。ただ、引数の順序を間違えるとバグにつながるからラベルを使うという側面もあるので、特に理由がないのなら、私はこの警告を有効にしておくのがいいと思います。

【俺の名前を】警告 9 または R【言ってみろ！】

レコードをパターンマッチする際、フィールドをすべて指定しないと警告されます。

とありますが……私がぼっちプログラマーだからか、めんどくささとのトレードオフを考えたときのメリットがわからないんですよね。コンパイルできた時点でレコードの型は特定されてるんじゃないの？と思ったんで、一部のフィールドの型と名前が共通するレコード型を複数用意して、デフォルトの警告セットでパターンマッチを試してみますと……

# type a = {
    a : int;
    b : int;
  };;
type a = { a : int; b : int; }

# type b = {
   a : int;
   c : int;
  };;
type b = { a : int; c : int; }

# let test { a = i } j = i + j;;
val test : b -> int -> int = <fun>

あらま、通っちゃったよ。確かにコンパイル時にレコードの型は特定されたようですが、 b が選択されています。俺が期待してたのは a なんだよ！（無茶振り失礼）

ちっ。すべての警告を有効にして再び実行してみます:

# let test { a = i } j = i + j;;
Warning 41: these field labels belong to several types: b a
The first one was selected. Please disambiguate if this is wrong.
Warning 9: the following labels are not bound in this record pattern:
c
Either bind these labels explicitly or add '; _' to the pattern.
val test : b -> int -> int = <fun>

警告 41 と警告 9 が出力されました。警告 41 のメッセージでは、パターンマッチに対応する型が複数見つかったために片方（b）を選択したとあります。

あん？レコードの型をきちんと指定させたいなら警告 41 を有効にすればいいのでは？不備を指摘されたら型名を指定すればいいわけだし:

# let test ({ a = i } : a) j = i + j;;
val test : a -> int -> int = <fun>

いけますね。一方、警告 9 のメッセージには "Either bind these labels explicitly or add '; _' to the pattern." とある通り、抜け道があるようです。どうやらワイルドカードは使えるんですね。やってみます。

# let test { a = i; _ } j = i + j;;
val test : b -> int -> int = <fun>

……何も注意されない。この警告、有効にする意味があるんですかね？

いや待て、この警告は 9 で先の警告は 41 です。数字の差が広いってことは……ぐぐってみますと、 9 はバージョン 3.12.0 で、 41 は 4.00.0 で追加されたようです。もしかすると、 9 のよりよい警告が 41 なのかもしれません。うん？それなら若者（ OCaml 歴的な意味で）は、いまさら 9 を使わずともええんちゃう？

ふむ、しかし何かが引っかかる……

うむ、どうも私はひでぇ思い違いをしているのかもしれない。もしかしてこの警告は、「複数あるレコード型のうち、いずれか一つを特定できないパターンマッチを指摘するために使う警告 ではない 」のではないでしょうか！

……。

てへぺろ☆ (・ω<)

【アウトオブ範囲だけど】警告 40【型指定さえあれば問題ないよねっ】

ドキュメントには "Constructor or label name used out of scope." とあり、その通りに読むならスコープ外のコンストラクタやラベル名が使われていれば警告します。でもここで言われているラベル名とは、どうもラベル付き引数のラベルではなく、レコードのフィールド名らしいです。私のコードではコンストラクタよりもレコードのフィールドで引っかかる場合が多かったです。

例えば、このようなモジュール定義があったとして:

module M = struct
  type t = 
    | Foo 
    | Bar 
    | Baz 
end

モジュール M とは異なる名前空間で（ module M ... end 外で）、適当な変数に Foo をセットしてみますと:

# let x = Foo;;
Error: Unbound constructor Foo

コンストラクタ Foo はモジュール M 以下の名前空間にあるので失敗します。なので、 Foo にモジュール M を修飾してやればコンパイルにパスします（または open M でもいいですが、それだと名前空間を汚すのでここでは置いときます）:

# let x = M.Foo;;
val x : M.t = M.Foo

しかし Foo が一箇所のみならこれでいいんですが、式中に何度も現れるといちいち修飾するのが面倒です。だったら、あらかじめ x の型を M.t に指定しておけばなんとかなりそうですよね。こうとか:

let x : M.t = ...

これなら右辺の式で Foo, Bar, Baz が使えそうです。するとどうなるか:

# let x : M.t = Foo;;
Warning 40: Foo was selected from type M.t.
It is not visible in the current scope, and will not 
be selected if the type becomes unknown.
val x : M.t = M.Foo

おっと、警告 40 はここで出るんですね。「 x は M.t だと宣言してるんだから、 Foo が M.Foo なのは自明でしょ」と言いたくなりますが、それは利便性を優先したいユーザーの理屈であって、コンパイラはコンパイラで問題を把握しています。「べっ、別にあんたの指定した型を信用してないわけじゃないんだからねっ！ただ、 Foo がスコープ内に見当たらなくって、あんたの指定した型から仕方なく選んで……そ、そう、仕方なくよっ！」みたいな。「スコープ内に見当たらない」から 「ちゃんと名前空間を指定せい」 というのがこの警告の趣旨なんでしょうね。……多分。

私は当初この警告も指定していたのですが、修正がめんどくさくなって止めました。自分のコードでは、この警告を無視しても致命的な問題はなさそうだったし。まあ、もしかしたら私がこの警告の重要性を理解しないばかちんであるだけかもしれませんが。

ちなみに、この警告を修正しようとして open するモジュールを増やすのは逆効果です。修正するなら局所的な open を使うか（ let open ... in てやつ）、素直にモジュール名を修飾しとくのがよさげです。ちなみにフィールド名を修飾するには data.Module.field と書きますが、実は Module.(data.field) とも書けるんですよ。知ってました？（ドヤァ

【そんな定義で大丈夫か？】警告 42【大丈夫だ、問題ない】

-- Disambiguated constructor or label name.

と書くとエラい人の格言みたいですね。どうでもいいって？

この警告は、一応型は決定できるけれども、同一の名前空間に同名のコンストラクタが存在する場合、または同名のフィールドが複数のレコードに存在する場合に出ます。警告 40 と同じく、ラベル名とはレコードのフィールド名のようです。

ここではレコードを例に挙げます。まったく同じフィールド名を持つレコードがいくつかあったとして（無理矢理に見えますけど実際そうしたい場合もあるんですよ！ソースは俺）:

type t = {
  x : int;
  y : int;
}

type u = {
  x : int;
  y : int;
}

型を指定した上でフィールドを参照すると警告されます:

# let x (r:t) = r.x
Warning 42: this use of x required disambiguation.

(r:t) と型を指定しているのでコンパイルは通してくれますが（警告 40 が同時に指摘される場合もあります）、フィールド x は複数のレコード t u に定義されていますよ、という警告です。試しにここから型指定を外してみますと:

# let x r = r.x
Warning 41: x belongs to several types: u t

警告 41 が出て、複数の候補があると指摘されます。警告なしの設定ではコンパイル時に適当に型が選択されるわけですが、モテない男は目の前にチャンスが複数ぶら下がっていても選べない……ってやかましいわ！

……さて警告 42 を避ける方法ですが、

適当な接頭辞をつけて名前の重複を避ける（ t_x u_x など）か、
異なる名前空間（モジュール）に振り分ける

のどちらかのようです。「いちいち型ごとにモジュールを作るの？」と訝しんだあなた、 1 モジュール 1 データ型スタイルというやり方もありますよ。 OCaml のことだし高尚な技法じゃないの？と怖がる必要はなく、「 OCaml じゃこう書いとけばメンテ楽じゃね？」程度の流行と捉えておけばいいんじゃねと思います。開発手法の流行り廃りってそんなもんでしょ？

ただし型名は修飾できないので（ r.t.x とか書けない）、いくらかコードが膨らむと気軽に修正できなかったりするんですよね。実際私のコードでは時間的・能力的に修正できていません（ビギナーですからね！）。ので、現在私は無視しています。新規にプロジェクトを始めるときは有効にしておいてもいいかもしれませんね。

【お兄ちゃんどいて！】警告 44, 45【そいつ使えない！】

open したモジュールが既存の識別子（警告 44 ）またはコンストラクタやラベル（警告 45 ）を上書きしてしまう（重複する）場合に警告されます。例によって実用的に何の意味もない次の例では、 open した List.length によって length が上書きされてしまいます。

# let rec length l = 
    let open List in
    length l (* List.length が優先される *)
    ;;
Warning 44: this open statement shadows the value identifier length (which is later used)

# length [];;
- : int = 0

この警告、ぱっと見役立ちそうでしょ？ Jane Street Core に依存している私の開発環境で有効にしてみますと、 @ 演算子を使っている箇所で引っかかります。

Warning 44: this open statement shadows the value identifier @ (which is later used)

これは　Core で @ が上書きされているためで、 a @ b と書いた箇所を Core.Std.(@) a b と書き直せば修正できるのですが、今度は |> が引っかかりました。まあ Core 自体が標準ライブラリを上書きするライブラリですから仕方がないのかもしれません。めんどくさいんで私はこの警告を無効にしてます。ついでに OCaml 4.01.0 変更点の「 open が既存の名前を覆い隠す時に警告」の節も読んでみるといいと思います。

さて、以上は 44 の話です。 45 ではコンストラクタとラベルが対象です。あるモジュールで、私はこのような型を定義しました。

type my_result =
  | Success
  | Failure of my_error

Success と Failure 、結果を示す型では使いたくなる名前です。ところが Failure は標準ライブラリで Failure of string と定義されているため、このモジュールを open すると警告 45 に引っかかります。

一応、 Failure を使っている箇所を モジュール名.Failure と書き換えれば修正できます。しかしそうなると、 open の利便性を捨ててモジュール名をあちこち修飾して回るか、 MySuccess とか MyFailure などの適当な接頭辞をつけて衝突を回避するか……めんどくさいんで私はこの警告を無効にしてます。が、依存するライブラリに影響がなければ有効にするのもいいのかもしれません。私はまだそこまで判断できませんので、一度試してみてはいかがでしょうか。

OPAM パッケージ化のススメ

SUZUKI Tetsuya — Thu, 23 Jan 2020 16:16:26 +0000

※この記事は 2016年06月03日に Qiita に投稿したものです。

OCaml を使い慣れてくると、そのうち依存するライブラリのバージョンの管理に悩まされるときが来ると思います。 OCaml のライブラリは依存するライブラリが多くて、 OCaml またはライブラリのバージョンを上げたらビルドできなくなったというトラブルが少なくないかと思われます。私も何度か困りました。 core とか見てください。一体いくつのライブラリに依存してるんですか。まあ core も含めてほとんどが Jane Street 製ですけど。

そこで OPAM パッケージ化の勧めです。大半の OCaml ユーザーは OPAM でパッケージ管理を行っているかと思います。パッケージ化というと敷居が高い気がしますが、そう難しくもありませんでした。 opam install を何度も実行して依存するライブラリをインストールしてはバージョン違いによるビルドエラーに悩む日々とサヨナラです。偉そうに言ってる私もビルドエラーの原因探しで困っていたところに「 OPAM で管理しなよ」と言われて今に至ります。

さらに詳しくは OPAM のマニュアルを参照してください。英語しかないけどがんばって。フランス語で書かれるよりましです。

OPAM パッケージ化のメリット

OCaml のバージョンを依存するライブラリのバージョンを指定できます。
依存するライブラリをインストールしてくれます。
ローカルのみの OPAM パッケージとして使えます。
インストールは opam install だけで OK です。

OPAM パッケージ化は、ファイルを一つ書けばいいだけで簡単です。ローコストでこれだけのメリットがあって損はありません。偉そうに言っている私も（ry

サンプルプログラム

サンプルとして RPN 電卓を作ってみました。あまり簡単な例を出してもかえって頭に入ってこないかなと思いまして、自分で使ってみようと思ってそこそこ作ってあります。ときどき Python の対話モードを電卓代わりに使っているんですが + を何度も書くのが面倒で、数字だけ並べて一気に足せると楽そうです。こんな感じ。 +! でスタック内の数値を全部足します。

$ ocalc
Try "h" for more information.
>>> 1 2 3 4 5 6 7 8 9 10 +!
55

先にインストールの方法について触れときます。このリポジトリをダウンロードしたら、トップディレクトリで次のコマンドを実行するとインストールできます。

$ opam pin add ocalc .
$ opam install ocalc

上のコマンドが、ローカルな OPAM パッケージをローカル OPAM リポジトリに追加します。追加したら、以降はいつもの opam install でパッケージをビルド、インストールできるようになります。アンインストールは opam uninstall ocalc です。

OPAM パッケージを作る

OPAM パッケージ化は簡単です。 opam という名前のファイルを用意するだけです。これが中身です。

opam-version: "1.2"
version: "1.0.0"
authors: "SUZUKI Tetsuya <tetsuya.suzuki@gmail.com>"
maintainer: "SUZUKI Tetsuya <tetsuya.suzuki@gmail.com>"
homepage: "https://github.com/szktty/ocalc"
bug-reports: "https://github.com/szktty/ocalc/issues"
dev-repo: "https://github.com/szktty/ocalc.git"
license: "Apache License, Version 2.0"
build: [
  [ "omake" "PREFIX=%{prefix}%" ]
]
install: [
  [ "omake" "install" "PREFIX=%{prefix}%" ]
]
remove: [
  [ "omake" "uninstall" "PREFIX=%{prefix}%" ]
]
depends: [
  "omake" { = "0.9.8.6-0.rc1" }
  "menhir" { = "20160504" }
  "spotlib" { = "3.1.0" }
]
available: [
  ocaml-version >= "4.03.0"
]

このファイルのフォーマットは YAML に見えなくもないですが OPAM 専用です。見た感じ適当にやってもどうにかなるでしょう。

license までの前半は特に説明不要かと思います。それ以降の項目はビルド処理と依存の指定です。 available で OCaml のバージョンを、 depends で依存ライブラリやツール＋バージョンを指定します（バージョン未指定でもOKです）。 ocalc は次のライブラリとツールに依存していますので、それを depends に記述しています。

OMake: ビルドツール
Menhir: いわゆる yacc
Spotlib: コンパクトな便利ライブラリ

特に明確な方針があるわけでもないんですが、 OCaml のバージョンは 4.03.0 「以降」、依存ライブラリはバージョンを「固定」しています。 OCaml 以外は仕様変更で ocalc がビルドできなくなる可能性が高いので固定しておきます。

build, install, remove の項目は、それぞれ OPAM から呼ばれたときに実行されるコマンドのリストです。 build と install は opam install 時に呼ばれ、 remove は opam uninstall 時に呼ばれます。基本的に OMake を呼ぶだけですが、 %{prefix} と書くとそこに OPAM のパスが置換されるので、それを OMake に渡しています。 OMakefile には PREFIX で指定されたパスにプログラムをインストールする設定を書いてあります。

build, install, remove は OPAM から呼ばれるだけの項目なので、実際にインストールやアンインストールを行う必要はありません。システムにインストールしたくないアプリケーションでも、ここを空にしておけば OPAM のバージョン依存管理の恩恵を受けられます。

注意点

OPAM に登録されているライブラリは、依存するライブラリのバージョンが指定されていないことがあります。例えば core はこれだけ依存ライブラリが指定されていますが、 OCaml のバージョンが指定されていません。最新版の OCaml で過去の core を使ったり、あるいは過去の OCaml で最新の core を使おうとすると、他ライブラリで指定される OCaml のバージョンと競合する可能性があります (現在は OCaml のバージョンが指定されています) 。既存のプロジェクトを OPAM パッケージ化する場合、できるなら OCaml とライブラリをすべて最新版に保つのがいいです。
もちろん OPAM 自身もバージョンが上がると仕様が変わります。当然設定ファイルの内容も変わったりするので、常に最新版を使いましょう。

型安全の夢を一行で打ち砕く黒魔術入門

SUZUKI Tetsuya — Thu, 23 Jan 2020 16:13:43 +0000

※この記事は 2018年01月13日に Qiita に投稿したものです。

※Reason 向けですが OCaml とほぼ共通します。

ドキュメントを眺めていて、こんな記述を見つけました。

型システムは完全に「安全」です。これは、コードがコンパイルされている限り、すべての型に誤りがないことが保証されることを意味します。従来のベストエフォートな型システムでは、例えば「Integer は決して null にならない」と言っていたとしても、言っているだけで、本当に決して null にならないということではありません。それとは対照に、純粋な Reason プログラムは null のバグはありません。

私は型理論に明るくないので「型の完全性」が何を示すのかはわかりませんが、型安全の抜け道は知ってます。私だけでなく、 OCaml ユーザーならわかるでしょう。

それは Obj.magic という関数です。この関数の型はこう定義されています。

let magic: 'a => 'b;

これを見て笑った人は、この記事を読む必要はありません。もうわかったはずです。

なんだこりゃ？と思った方は、一つ冷静になって考えてみてください。この関数は、 任意の型 'a を、任意の型 'b に変換 します。当然ながら、 'a と 'b は同じ型である必要はありません。 'a が int で 'b が bool でもいいわけです。

この型の関数の実装を考えてみてください。処理内容はどうでもいいものとします。関数の型が 'a => 'b になれば OK です。

例えば、 int を bool に変換する関数は簡単に書けるでしょう。処理内容はどうでもいいので、単に true を返すだけでも構いません。次に、 int を任意の型 'b に変換する関数はどうでしょうか。もちろん 'b は関数が呼び出される文脈によって変わります。 'b は bool かもしれませんし、 string かもしれません。

let f = (value: int) : 'b => {
  /* どうする？ */
};

何か思いつきます？無理じゃないですか？任意の型を戻り値にするとはどうすればいいのか。任意の型を生成するとは？ int 値を任意の値に変更する？どうやって？

Obj.magic はどうにかしちゃいます。型の上では任意の型 'a を任意の型 'b に変換します。ただし、 Obj.magic は何もしません。引数の値をそのまま戻り値にします。型だけが変わります。つまり、 int の値を string として扱えるようになります。

/* 見た目は文字列、中身は整数！ */
let f = (a: int) : string => Obj.magic(a);

/* 文字列の長さを表示する */
Js.log(String.length(f(123)));

オンラインでこのコードを入力してみてください。出力には undefined と表示されるはずです。

出力される JavaScript のコードを見ればはっきりわかります。

// Generated by BUCKLESCRIPT VERSION 1.9.2, PLEASE EDIT WITH CARE
'use strict';


function f(a) {
  return a;
}

console.log((123).length);

exports.f = f;
/*  Not a pure module */

整数 123 は length プロパティを持っていないので結果は undefined です。 Reason の型検査をすり抜けてしまいました。ちなみに OCaml の出力だと Obj.magic が残ります。元々 OCaml のライブラリの API なので。

let f (a : int) = (Obj.magic a : string)
let _ = Js.log (String.length (f 123))

Obj.magic はどうしても使わなければならない場面があり、実際に ReasonReact でも使われています。普通は使いませんし推奨もしませんが、 Obj.magic を使っているライブラリは型検査をすり抜けたバグを含む可能性がある、ということを頭の隅に置いておくと、いざというときにデバッグにかかる時間を削減できるかもしれません。

"type t" とは何か

SUZUKI Tetsuya — Thu, 23 Jan 2020 16:11:05 +0000

※この記事は 2018年01月12日に Qiita に投稿したものです。

※Reason 向けの内容ですが、 OCaml とも共通します。

Reason で書かれたコードを見ていると、ところどころで type t という一文字の型名を目にします。例えばこういうの:

module Synthetic = {
  type tag;
  type t = synthetic(tag);
  ...
}

これは 1モジュール1データ型主義という OCaml の一慣習から来ています（いると思われます）。

Reason のドキュメントにレコード定義の一例があります。

type person = {age: int, name: string};
type monster = {age: int, hasTentacles: bool};

どちらのレコードも age という同名のフィールドを持ちます。 Reason のレコードは名前空間が独立しておらず共有されるため、型推論時の person と monster の区別はフィールド名の組み合わせで判断されます。レコードの生成時に name フィールドがあれば person 型、 hasTentacles フィールドがあれば monster 型と判断されます（もちろん明示的にレコード型を指定することもできます）。

/* person */
let me = {age:100, name:"me"};

/* monster */
let me = {age:100, hasTentacles:true};

では、まったく同じフィールドを持つレコード型があったらどうでしょうか。

type person = {age:int, name:string};
type monster = {age:int, name:string};

/* どっちのレコード？ */
let me = {age:100, name:"me"};

特に型の指定がなければ、フィールド名では型を判断できません。このような場合、 Reason では最後に定義された型とされます。 me は monster 型です。

ですので、次のように person を引数に受け取る関数に me を渡すと型エラーになります。

let me = {age: 100, name: "me"};

/* person 型の引数を取るだけで何もしない関数 */
let f = (who: person) => ();

f(me);

コンパイルエラー:

  13 │ let f = (who: person) => ();
  14 │ 
  15 │ f(me);

  This has type:
    monster
  But somewhere wanted:
    person

me は monster 型だと判断されました。この場合は me の型を person と明示的に指定すれば大丈夫です。

let me: person = {age: 100, name: "me"};

OCaml だとフィールド名が重複すればコンパイル時に警告されます。 Reason の唯一の工夫のように見えますが、かえって落とし穴ができてしまった気もします。

ただし、既存のレコードとフィールド名が重複していると警告 42 で注意されます。 (デフォルトの警告の設定では無効です)

   9 │ };
  10 │ 
  11 │ let me:person = {age: 100, name: "me"}; // ``age`` の部分がハイライトされる
  12 │ 
  13 │ let f = (who: person) => ();

  this use of age required disambiguation

ここで元の問題に戻ります。以上の通りレコードは名前空間にならないので、フィールド名が重複する複数のレコードを定義する場合は、フィールド名に適当な接頭辞をつければ問題は回避できます。でも person_age や monster_age といちいちやるのはあまりかっこよろしくない。だからそれぞれのレコード型に専用のモジュールを用意すればフィールド名の重複を気にかけなくていい:

module Person = {
  type t = {
    age: int,
    name: string
  };
};

module Monster = {
  type t = {
    age: int,
    name: string
  };
};

このときに使う型名が t です（"type" の "t" かな？）。かつてのレコード person と monster はそれぞれ Person.t と Monster.t として定義されます。 t とつく型は、そのモジュールの中心的なデータ型だとわかります。インターフェースファイルである .rei と t を探せば、 API のだいたいの意味が推測できます。

以上です。 Reason は OCaml を丸ごと新しい文法で覆っただけなので、 OCaml の不便な点も、不便を解消するためのイディオムもそのまま引きずっています。改善すべき点は文法以外にもあるんじゃないですかね...

私的即席プラクティスパターン（※古い内容です）

SUZUKI Tetsuya — Thu, 23 Jan 2020 16:05:21 +0000

※この記事は 2015年12月25日に Qiita に投稿したものです。

※ Rust 1.4.0 時の内容でありかなり古く、 Rust 的に褒められた作法ではありません。消そうか残そうか迷いましたが、いまだそこそこ閲覧があり、こういう形で学習した人間もいるということで残しておきます。ご了承ください。

Rust のコードを書いていて、個人的に躓きがちだった点をまとめてみました。あくまで私的な意見で、 Rust の公式的な作法ではありません。

想定する Rust のバージョンは 1.4.0 stable です。 1.5.0 でも特に問題ないとは思いますがわかりません。また、 unstable な API には触れません。

方針

これらの私的なパターンもしくは Tips の方針は、 「コードが汚かろうが無駄な処理が多かろうが、動けば正義」 です。

Rust はリソース管理の複雑さと強い型付けによってコンパイルエラーが出る機会が多く、慣れないうちは修正方法すらわかりません。始めからすべての仕様を把握しようとすると、コンパイルエラーの修正でいっぱいいっぱいになって、トライ＆エラーどころじゃなくなると思います（ただ、エラーメッセージはかなり親切です）。そこで、まずはコンパイルエラーを最小限にして少しずつ慣れていこう、というスタンスです。そういう私も、きっと闇の軍団にコードレビューされたら葬られるようなコードを書いてると思います。

最初から礼儀正しいコードを書きたい人にとっては害悪なだけかもしれません。まあ、それはそれで清く正しくコンパイルの闇に飲まれてみるのもありかなと思います。

基本的な型

&str と String

文字列を表す型は二つあります。 str と String です。 str がプリミティブな型で、 String は Rust 自身で実装されている型です。どちらの型も相互変換が可能です。

文字列型が二つもあるなんて面倒だなあと思いますが、積極的に使うのは String です。 str の方は、基本的に &str という借用の形で使います。

プリミティブな型である str は、普通使わないし使えないと考えていいと思います。 Rust のコンパイラは、コンパイル時にサイズが決定できない型を変数の型に指定するとエラーにします。で、 str もコンパイル時にサイズを決定できない型です。この意味がまだわからなくても大丈夫です。とにかく、次のような変数は定義できません。

let s: str;

しかし、 &str という借用の型であればコンパイル時にサイズを決定でき、変数の型として使えます。とにかくそういうものなのです。

それで &str がどこで使われるのかと言うと、一つは文字列リテラルです。文字列リテラルの型は &'static str で、 'static は生存期間を示しますが、それはさておき &str です。これ以外で str を生成する機会はまずないと考えていいと思います。文字列を生成したり編集したりする場合は String を使います。

String は、動的に生成できる可変の UTF-8 の文字列です。この文字列は動的にサイズを伸縮でき、内容を変更できます。コンパイル時にサイズを決定できるため、変数の型に指定できます。とりあえずの理解は「 String を使え」でいいと思います。

で、自分から文字列を生成・操作するなら String でいいんですが、 &str は引数や戻り値にたびたび登場し、 String への変換を行う必要も出てきます。また、文字列リテラルを String 型の変数にセットしたい場合も、 &str から String の変換が必要です。

&str から String の変換は to_string() メソッドで可能です（ API に ToString トレイト実装済みと書かれていれば使えます）。人のコードでやたらと見かける to_string() は、それだけ &str が引数や戻り値として使われていることを示しています。

let s: String = "hello".to_string()

ただ、 to_string() はゼロコストというわけにはいきません。具体的には、フォーマット化によって文字列化するために、メモリーアロケーション＋フォーマット化のコストがかかります。 &str に限って言えば、 to_owned() を使えばメモリーアロケーションのみで済むので、余裕があれば頭の隅にでも置いておくといいと思います。

「 String を使え」と言っておきながら &str が頻出するのですが、 &str を使うのには理由があります。ただ、慣れないうちは &str と String の関係を理解できるまで String で済ませれておけばいいんじゃないかと思います。とにかく &str を受け取る場面では to_string で String に変換することにして、 &str と String について理解する労力を他に回せばいいと思うのですよ。

で、次の問題は、引数に &str を受け取る関数はあるけど String を受け取る関数がない状況です。例えば String がいきなりそれです。文字列を追加するメソッドで、 &str を受け取る push_str() はありますが、 String を受け取って欲しい push_string() はありません。「オメー何で自分を使わねえんだよ」と当初思いました。

そういう場合は String を &str に変換すればいい、とだいぶ後になって理解しましたが、その変換方法がまたトリッキーで、「 String の借用 = &str 」の関係が成り立ちます。つまり、 String の型の変数の先頭に & をつければ &str の型の引数に渡せます。

fn print_str(s: &str) {
    println!("str = {}", s)
}

fn main() {
    print_str("hello");
    let world: String = "world".to_string();
    print_str(&world);
}

まとめます。相互変換は次の方法で行います。

&str -> String の変換は to_string() で行う
String -> &str の変換は & をつける

&str と String の使い分けの方針は、

引数として受け取る文字列は &str
構造体のフィールドとする文字列は String
戻り値にする文字列は String

と大雑把に捉えておいていいのではないかと思います。混乱しそうであれば、すべて String でもいいのではないかと思います。

&'static str

文字列リテラルの型です。 'static は特殊な生存期間で、静的にメモリが確保される文字列です。プログラムの実行中はずっと生存します。

Vec<T>

リストです。 T にはリストの要素の型が入ります。

Vec を使うのに何らかのモジュールをインポートする必要はありません。

HashMap<K, V>

キーがハッシュ値であるマップです。 K がキーの型で、 V が値の型です。HashMap を使うには、 std::collections::HashMap モジュールをインポートする必要があります。

ハッシュ値を算出できなければならないため、キーの型は Eq トレイトと Hash トレイトを実装する必要があります。これは型の定義時に #[derive(PartialEq, Eq, Hash)] を指定すれば簡単です。 Hash トレイトを適用できない型が含まれる場合は自前で実装しなければなりませんが、慣れないうちはハードルが高いかもしれません。その場合はハッシュ値を算出できる他の型をキーにすることを検討してはどうでしょうか。

HashSet<K, V>

要素が重複しない集合です。重複の検査にハッシュ値を使うため、 HashMap と同様に Eq トレイトと Hash トレイトを実装する必要があります。 HashSet を使うには、 std::collections:: HashSet モジュールをインポートする必要があります。

Option<T>

「あるのかないのか」を表す型です。何に使うんだ？と言うと、他の言語で「値がない」ことを nil や null で表していた処理を None と Some(T) に置き換えればいいと思います。

Result<T, E>

処理の成否を表す型です。成功時の値の型が T 、失敗時の値の型が E です。 Rust には捕捉可能な例外処理機構はなく、エラーの可能性を示したいときはこの型を使います（ panic! マクロがエラーメッセージの表示に使えますが、表示後にプログラムが終了します）。積極的に使っていくべきです（「あ、この処理は引数の値次第でエラーにすべきだな」と思ったときが使いどころです）。 try! マクロと組み合わせて使うと便利です。

ちなみに、同名の型が std::io モジュールにもあります。こちらの Result は、入出力に関するエラー io::Error をエラー値に持つ Result として定義されています。簡単に言うと、 io モジュールの関数の戻り値に毎度 Result<T, io::Error> と書くのが面倒になった（のと、エラー値の型を隠蔽したい）ので、一つの型として定義しておいた、と考えていいと思います。

type Result<T> = Result<T, std::io::Error>;

Box<T>

任意のデータ型 T の値をラップする型です。一体何の役に立つのかと言うと、再帰的な構造体や列挙体の定義に使います。こんな感じです。

#[derive(Clone)]
struct Employee {
    name: String,
    boss: Box<Option<Employee>>
}

このオブジェクトを生成する例:

Employee { name: "John".to_string(), boss: Box::new(None) }

この構造体では Option を Box でラップしていますが、ラップをしないと生成できなくなってしまうからですね。 None の位置に何を入れるか考えてみるとわかると思います。

Box でラップされた中身を取り出すには、式の前に * をつけます。

let jack = Employee { name: "Jack".to_string(), boss: Box::new(None) };
let john = Employee { name: "John".to_string(), boss: Box::new(Some(jack)) };
match *john.boss {
    None => println!("boss is none"),
    Some(ref boss) => println!("boss is {}", boss.name)
}

よく使うマクロ

print!, println!

標準出力にフォーマットしたテキストを出力します。とりあえず覚えておくといいフォーマットは "{}" です。こんな感じで使います。当面は "{}" だけ覚えてればなんとかなります。

let p = "hello";
println!("data = {}", p)

ただし、これで出力できる値には制限があり、任意のすべての値を出力できるわけではありません。コンパイル時に Display がどうのというエラーが出た場合は、 String に変換するメソッドを実装するなどして、 String に変換した値をフォーマットに指定すれば大丈夫です。

format!

引数は print! と同じですが、こちらはフォーマットしたテキストを String で返します。他の言語で言う sprintf です。文字列の結合代わりに使うのも便利です。

write!, writeln!

これも print! と同じくテキストをフォーマットします。ただし print! と違って出力先はバッファです。具体的には std::io::Write トレイトを実装したオブジェクトです。わかりやすい例は、文字列バッファである String です。 Vec も対応しています。

use std::fmt::Write;

fn main() {
    let mut buf = String::new();
    write!(buf, "hello, ");
    write!(buf, "world!");
    println!("formatted: {}", buf);
}

なお、 write! は戻り値が Result<usize> です。上記のコードのように戻り値を処理しない場合は、コンパイラの設定次第で警告が出ます。

panic!

回復不能なエラーを発生させます。このエラーは捕捉できず、プログラムはエラーメッセージを表示して終了します。エラーメッセージは、 print! と同様のフォーマットで指定します。

panic!("error")

unimplemented!

"not yet implemented" というメッセージを表示する panic! です。未実装の処理を後回しにしたいときに使ってもいいし、使わなくてもです。使う場合は、引数なしでこのように呼びます。

unimplemented!()

unreachable!

"internal error: entered unreachable code" という、到達不可能を示すメッセージを表示する panic! です。到達不可能のはずの箇所で使ってもいいし、使わなくてもいいです。

このマクロの引数は print!/format! と同じか、 unimplemented! と同様に引数なしでも構いません。フォーマットを与えた場合は、上記のメッセージに続けて表示されます。

// thread '<main>' panicked at 'internal error: entered unreachable code: test', <anon>:3
unreachable!("{}", "test")

try!

Result 型の値に対して使うマクロです。値が Err であれば、それを戻り値として関数から脱出し、 Ok であれば、 Ok が保持する値を返します。何やら複雑そうですが、 Result がエラーを示したら関数を終了したい、そうでなければ処理を続けたい、という状況は間々あります。その度にいちいち match で

let value = match exp {
   Err(e) => return Err(e),
   Ok(v) => v
};

と書くのは面倒です。 try! を使うと、上のコードはこう書けます。

let value = try!(exp);

このマクロのポイントは return で、関数では「現在の関数から脱出する処理」を実装できません。 Result と併用すると、エラー処理を書きやすくなるでしょう。

ちなみに、 Option に対して同等の処理を行うマクロはないようです。もちろん自分で定義するのは自由ですが、あったらあったで、意外と使う機会があるようでないんじゃないかと思います。参考までに、 None であれば戻り値を None として関数を脱出するマクロの実装例を挙げておきます。

macro_rules! expect {
    ($e:expr) => ({
        use std::option::Option::{Some, None};

        match $e {
            Some(e) => e,
            None => return None,
        }
    })
}

fn test() -> Option<String> {
    let opt1: Option<String> = Some("hello".to_string());
    let opt2: Option<String> = None;
    let s = expect!(opt1);
    println!("opt1 = {}", s);

    let s = expect!(opt2);
    // 実行されない
    println!("opt2 = {}", s);

    None
}

fn main() {
    let _ = test();
}

vec!

任意の数の式の並びから Vec オブジェクトを生成するマクロです。文章だとわかりにくいですが、要はこういう使い方をします。

// 要素が 1, 2 , 3 である Vec オブジェクトを生成する
let x: Vec<u32> = vec![1, 2, 3];

このマクロの引数は中括弧 [..] で囲むので注意です。

assert!, assert_eq!

アサーションです。引数の値が　false であれば panic を発生させます。

debug_assert!, debug_assert_eq!

こちらもアサーションですが、コンパイルオプションに -C debug-assertions を指定したときにのみ有効になります。

コーディングスタイル

一度に 5 行以上書かない

Rust は他の言語と比べると、一度に（コンパイルを挟まずに）長いコードを書きにくいと思います。型推論のある言語ではそうなりがちだと思いますが、 Rust はそれに加えて所有権のエラーがつきものです。うっかりすると修正するうちに実装の目的を忘れてしまう量のエラーが出るので、少しずつコンパイル＆修正を繰り返しながら進めるといいと思います。

コンパイル時のエラーメッセージはよく読む

Rust でのコンパイル時のエラーメッセージは長いです。エラーの原因に加えて、その他の情報もたくさん表示されます。しかし、わかりにくいように見えて、 help から始まるメッセージはかなり親切だったりします。

特に生存期間に関するエラーでは修正例のコードが表示されることがあるので、詰まったらエラーメッセージをよく読むべきです。エラーメッセージや修正例のコードを読んでもその意図がわからなければ、借用を使わずに済む方法を考えた方がいいでしょう。

可変なコレクションには mut を指定する

プラクティスというか、単に必須事項なんですけど。コレクションにオブジェクトを追加するなどの破壊的な操作を行うコードがエラー扱いされた場合、変数定義で mut を付け忘れるケアレスミスが（私は）よくあります。「なんでこれがエラーなんだ？」と思ったら、まず変数定義を確認するといいと思います。

エラーハンドリングは Result 型で

ここに、従業員を表す次の構造体があるとします。とりあえずは従業員の名前のフィールドのみ用意するとします。

#[derive(Clone)]
struct Employee {
    name: String
}

Employee オブジェクトを生成するとき、 Employee { name: .. } と直に生成してもいいですが、コンストラクタ関数を実装するとします。シンプルに考えると、関数の型はこうでしょうか。

fn new(name: &str) -> Employee

どうせなら入力する名前をチェックしたいですね。空の名前を入力されても困りますから、受け付けられない名前であればエラーとします。

Result 型を使うタイミングはここです。名前が問題なければ Employee オブジェクトを返し、問題ありならその原因の旨を示すメッセージを返すとします。このエラー処理を捕捉不可能な panic! でやると、プログラムが終了してしまうので注意です。

Result 型を使うと、コンストラクタ関数はこのように実装できます:

impl Employee {
    fn new(name: &str) -> Result<Employee, String> {
        if name.is_empty() {
            Err("name must not be empty".to_string())
        } else {
            Ok(Employee { name: name.to_string() })
        }
    }
}

これなら、 Employee オブジェクト生成時のエラーを安全に処理できます。型宣言からもエラーが発生する可能性があるとわかるので、積極的に使いましょう。 try! マクロについても知っておくといいです。（具体例が思いつかなかった）

最初のうちはエラー値の詳細は置いといて、 Result<T, ()> などと unit 型にしておけばいいと思います。 Option<T> 型で代用したくなることもあるかもしれませんが、 Option 型は目的が異なるので避けましょう。

整数や文字列に特別な意味を持たせない

例えば、どの言語にも数値やオブジェクトの比較を行う関数が用意されています。比較の結果は概ね「等しい、小さい、大きい」のいずれかで、これらを表すのに "0, -1, 1" の整数を割り当てる言語があります。もしくは、それらの整数を定数として定義しているかと思います。 Rust ではこのような整数の使い方、整数に特別な意味を持たせる使い方は避けるべきです。

Rust では列挙体で値の意味を表します。なんだか抽象的な説明ですが、前述の比較の結果は、 Rust ではこう定義されています。

pub enum Ordering {
    Less,
    Equal,
    Greater,
}

列挙体を使うメリットは型検査です。これを整数で表してしまうと、定義外の数値を渡しても型検査が通ってしまいます。

また、構造体と同様に、列挙体にもメソッドを定義できます。例えば Ordering に定義されている reverse() メソッドは、比較の結果を逆転させます。昇順と降順を切り替えるのに使えます。

bool に特別な意味を持たせない（二択でも列挙体を定義する）

前節の続きです。 bool にも特別な意味を持たせないようにすべきです。例えば、扱う値が整数か浮動小数点数のどちらかだとしたら、「 true なら整数、 false なら浮動小数点数」という二択に bool を割り当てるべきではありません。代わりに列挙体でこう定義するといいです。

enum ValueType {
    Int,
    Float
}

unwrap() の落とし穴

Option 型と Result 型には、一部の列挙体が持つ値（ Some または Ok ）を取得できる unwrap() メソッドがあります。このメソッドは列挙体が None や Err だと panic を発生させますが、その場合はバックトレースの最後尾が unwrap の実装元になります（ lib/std/option.rs とかそんなの）。 unwrap() を呼び出した位置ではないので気を付けたいです。

バックトレースを有効にしても、 unwrap() を呼び出した行番号まではわからないようです。どうしても unwrap() の呼び出し位置を確認したいなら、 unwrap() 相当の処理をマクロで実装するといいかもしれません。こんな感じでしょうか。

// Option.unwrap()
macro_rules! unwrap_opt {
    ($x:expr) => {
        $x.unwrap_or_else(|| panic!("unwrap failed"))
    }   
}

// Result.unwrap()
macro_rules! unwrap_result {
    ($x:expr) => {
        $x.unwrap_or_else(|_| panic!("unwrap failed"))
    }   
}

レコードのパターンマッチではフィールド値の変数名を省略する

レコード型（構造体、列挙体）やタプルのパターンマッチでは、フィールド値を代入する変数の記述を省略できます。楽ですので省略しましょう。

struct Person {
    name: String
}

fn main() {
    let me = Person { name: "me".to_string() };
    match me {
        // { ref name: name } と書かなくてもよい
        Person { ref name } => println!("name = {}", name)
    }
}

クロージャーに関する所有権でつまずいたら move を指定してみる

クロージャー内の所有権の扱いはいくらか複雑です。所有権に関するコンパイルエラーが出るのに原因も修正方法もわからないときは、クロージャー式の前に move キーワードをつけてみるとコンパイルにパスするかもしれません。

理屈もわからないのにやってみろというのも適当ですが、先に理屈を理解するには Rust は難しいのではないかと思います。どうしてもクロージャーを使ったコードがコンパイルできないのであれば、不格好でもクロージャーを使わないコードに書き換えてはどうでしょうか。

また、クロージャーを引数に取る関数を実装しようとすると、関数の型定義がいくらか複雑になります。慣れないうちは、安易にクロージャーを多用しない方がいいのではないでしょうか。

再代入可能なグローバル変数を使わない

実行中に再代入可能なグローバル変数（ static mut で定義する可変の静的変数）の内容を書き換えるコード、誰もが（？）つい一度は試してしまうと思います。できることはできるのですが、本当にこの方法でなければできない処理でもなければ、可変のグローバル変数の使用は避けましょう。

例えば、実行中に書き換える目的で、 Option 型のグローバル変数を定義するとします。次のコードは問題なくコンパイルできます。

static mut COMMAND: Option<&'static str> = Some("default");

fn main() {
    // static mut の変数へのアクセスは unsafe で囲む
    unsafe {
        COMMAND = Some("mycommand");
        println!("command = {}", COMMAND.unwrap())
    }
}

これがコンパイルをパスするのは、 Option 型の内容が即値（文字列定数）だからです。これを動的に生成される String にするとコンパイルできません。

// None にしても同様
static mut COMMAND: Option<String> = Some("default".to_string());

エラー:

<anon>:3:38: 3:65 error: mutable statics are not allowed to have destructors [E0397]
<anon>:3 static mut COMMAND: Option<String> = Some("default".to_string());
                                              ^~~~~~~~~~~~~~~~~~~~~~~~~~~
<anon>:3:38: 3:65 help: see the detailed explanation for E0397
<anon>:3:43: 3:64 error: method calls in statics are limited to constant inherent methods [E0378]
<anon>:3 static mut COMMAND: Option<String> = Some("default".to_string());

ですので、可変なグローバル変数を有効利用できる状況は非常に限られます。 unsafe の指示が必要な処理はバグの原因にもなりますから、他の方法を検討しましょう。

unsafe は諸刃の剣

生ポインタやスレッドセーフなどの安全ではない処理は、通常コンパイルエラーになります。どうしてもそういった処理を行いたければ、 unsafe ブロック内に記述するとコンパイルをパスできます。ただし、より柔軟な処理ができる一方で、当然安全じゃありませんからバグの原因にもなります。「 unsafe を使わざるを得ない」と思ったら、一旦考え直しましょう。

実行速度を過信しない

ネイティブコードにコンパイルする言語だからと言って、 Rust で書けば何でも速くなるということはないです。当然、サードパーティーのライブラリが速いとも限りません。わざわざ言われなくてもわかってる、と言われそうですが念のため。

私が書いてみた範囲では、サイズの大きいオブジェクトを含む Box のコピーで遅くなっていた場合がありました。とは言え必ずしも Box がネックになるとは限りませんし、今後の開発で変わるかもしれません。

所有権と生存期間

不要なクローンをしない

ここで言う不要なクローンとは、 clone() メソッドを呼び出さなくてもコンパイルエラーにならない処理です。

所有権のエラーに嫌気が差して、とりあえずクローンしとけという考えはお勧めしません。別にクローンのコストを削れなどの実用上の理由ではなくて（もちろんオブジェクトの内容如何でコストが高い場合もあります）、クローンの意味を理解する機会を奪ってしまうからです。エラーが出たら、エラー箇所の周辺に clone() を入れればだいたいは解決できると思うので、そこは一つ我慢して、エラー＆修正の経験値を積むといいと思います。

明確な理由を説明できないうちは借用を使わない（例外もある）

Rust と言えば所有権、 Rust と言えば生存期間です。所有権を奪いたくなければ借用を使うことになり、借用を使うなら生存期間を管理する必要があります（生存期間は、コンパイラが推論できる範囲で省略できます）。所有権、借用、生存期間は扱いが複雑なので、ドキュメントやブログなどで詳しく取り上げられたりしてますが、残念ながら学習コストは低くありません。

ここからは個人的な意見ですが（この記事すべてがそうですが）、 Rust に慣れるまでは、これらの理解を棚上げにしてもいいと思います。特に構造体や列挙体のフィールドに借用を持たせるとなると、生存期間の理解が必要です。借用を使わなければ絶対に実装できないプログラムはそうそうあるものでもないと思います。なぜあなたのコードで借用を使わなければならないのか、その理由を明確に他人に説明できないようでしたら、ひとまず借用の使用は避けておくといいと思います。

しかし、それでも借用を使うべきであろう場面もありますので、これに続く節も合わせて参考にしてください。

少々古いドキュメントですが、所有権についてこう触れられています。

If you have good reason. It's not polite to hold on to ownership you don't need, and it can make your lifetimes more complex.

不要に所有権を持つと生存期間の管理が複雑になるからやめとけ、という忠告です。イディオム的でもないよともあります。確かに単純な関数の引数くらいなら、引数で借用すれば所有権を気にする手間が減ると思いますけど、私なんかは Rust に慣れないうちは手間がかかっても所有権の移動のみでなんとかやる方が楽なんじゃないかと思います。

むしろ、安易に借用を使わない＝不変のオブジェクトを次々と生成しながら処理するコードを書けるスキルの方が、後々重要になるのではないか、とすら思います（ C++ の人たちに怒られるかな？）。借用を使わなければ、所有権絡みのエラーは clone() を闇雲に挟めばなんとかなります。数打ちゃ当たります。打ちまくってるうちに、エラー原因となるコードの勘所もつかめると思います。

ただ、 Box や標準ライブラリを使う上では借用を気にしなければならない機会も多いのですが、そこは & や * を適当に付けて、気合いで乗り切って頂きたいと思います。

所有権を渡す（＝借用の使用を避ける）ことのデメリット

上の節の主旨は「わかんなきゃ借用は使わなくても（所有権を渡しても）いいんじゃない？」なんですが、デメリットもあるんだと押さえておくといいと思います。

デメリットの一つはコストです。ある値を複数箇所で使うときにいちいち所有権を渡すとなると、その数だけ新しい値を生成するかコピー（クローンもコピー手段の一つ）するかして、新しい所有権を用意する必要があります。当然ながら、生成もコピーもコストがかかります。

もう一つは、コピーできない値が扱いにくくなることです。他の節で「所有権に関するエラーが出たらクローンしとけばなんとかなる」などと言いましたが、逆に言えば、クローンまたはコピーができなければどうにもならない可能性があります。クローンできない（ Clone トレイトを実装していない）値も多々あります。

例えば、 File オブジェクトがそうです。ここに、引数に File オブジェクトを所有権ごと受け取る関数があるとします（内容は適当です）。

fn read_all(mut f: File) -> String {
    let mut buf = String::new();
    f.read_to_string(&mut buf);
    buf
}

この関数を呼び出すときは、引数に渡す File オブジェクトの所有権を渡さなければならず、呼び出し後はファイル操作ができなくなります。引数にクローンした値を渡そうにも、 File オブジェクトはクローンできません。

use std::fs::File;
use std::io::{Read, Seek, SeekFrom};

fn read_all(mut f: File) -> String {
    let mut buf = String::new();
    f.read_to_string(&mut buf);
    buf
}

fn main() {
    let mut f = File::open("foo.txt").unwrap();
    let s = read_all(f);

    // error: use of moved value: `f`
    f.seek(SeekFrom::Start(0));
    ...
}

まあこの程度であれば、次のように変更するなどして File の所有権を返せば処理を続けられます。

fn read_all(mut f: File) -> (File, String) {
    let mut buf = String::new();
    f.read_to_string(&mut buf);
    (f, buf)
}

fn main() {
    let mut f = File::open("foo.txt").unwrap();
    let (mut f, s) = read_all(f);
    f.seek(SeekFrom::Start(0));
}

ですが、万事そういうわけにもいかないでしょう。また、あらゆる場面で所有権の授受をしていてはコードが複雑に入り組んでしまいます。 Rust に慣れてきたら、まずは引数から借用を取り入れてみるといいかもしれません。構造体のフィールドに借用を含める場合と違い、だいたいは生存期間を気にする必要はない（省略可能）はずです。

ちなみに借用を使うと、上のコードはこう書けます。

use std::fs::File;
use std::io::{Read, Seek, SeekFrom};

fn read_all(f: &mut File) ->  String {
    let mut buf = String::new();
    f.read_to_string(&mut buf);
    buf
}

fn main() {
    let mut f = File::open("foo.txt").unwrap();
    let s = read_all(&mut f);
    f.seek(SeekFrom::Start(0));
}

型

戻り値を使わない式をエラーにする (unused result which must be used)

セミコロンで区切られた式の値が unit 以外のとき、その値に対して何も操作をしなければ、警告 unused_must_use が表示されます（またはエラー）。例えば次のコードです。

// エラーにする
#![deny(unused_must_use)]

use std::fmt::Write;

fn main() {
    let mut buf = String::new();
    write!(buf, "abc");
    ()
}

<std macros>:2:1: 2:54 error: unused result which must be used
<std macros>:2 $ dst . write_fmt ( format_args ! ( $ ( $ arg ) * ) ) )
               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<anon>:7:5: 7:24 note: in this expansion of write! (defined in <std macros>)
<anon>:1:9: 1:24 note: lint level defined here
<anon>:1 #![deny(unused_must_use)]

このコードのエラー箇所は write!(buf, "abc"); です。セミコロンを終端とする式の値は unit であるべきですが、 write! マクロの戻り値は Result<(), std::fmt::Error> です。 Rust では式の値が操作（代入も含む）されないと、 "unused result which must be used" というメッセージで警告されます。値を無視すればバグにつながる可能性があります。

次の節に続きます。

戻り値を無視するには

write! のような連続して使うマクロや関数では、すべての呼び出しで戻り値を処理するのが面倒になることもあります。エラー時に落ちたり見逃したりしてもよければ、戻り値を無視する方法がいくつかあります。

_ で始まる変数に値を代入する（ _ を変数名の先頭に付けると、コードブロック内で使わなくても警告されません）
#[allow(unused_must_use)] コンパイラ属性を指定する
戻り値を無視するマクロを定義する

手っ取り早いのは let _ = .. でアンダースコア付きの変数に代入する方法ですが、私は同等のマクロを定義して使っています。これだと _ への代入よりも無視の意思が明白です。

use std::fmt::Write;

macro_rules! ignore {
    ($x:expr) => {
        {
            let _ = $x;
            () // unit を返せばよい
        }
    }   
}

fn main() {
    let mut buf = String::new();
    ignore!(writeln!(buf, "無視してんのよ"));
}

もちろん、無視しないに越したことはないです。

総称型の型パラメーター名に意味はない

Vec<T> とか Result<T, E> などの T とか E の名前に意味はありません。慣習的に一文字で表しているだけで、 Type や Error などの頭文字を使うことが多いです。

自分で定義する構造体の型パラメーターの数が多くてわかりにくいようであれば、関連型の使用を検討するといいかもしれません。関連型は難しそうに見えても、単に書き方を変えただけです。

型推論に頼り過ぎない：時には型を宣言する

タプルやコレクションの変数を定義するとき、以降の処理が複雑になりそうであれば、先にコレクションの型を宣言しておくとあとで楽です。

こんな感じ:

let names: Vec<String> = Vec::new();

型推論のエラーは、自分の推測と離れた位置で発生する可能性があります。複雑な型になるとそうなりがちで、間違った型を基準に他の部分も推論が進むと、その結果思い掛けない位置が型エラーとして表示される場合があります。残念ながら、間違いの正確な位置を特定する決定的な方法はありません。

そこで、あらかじめ変数の型を宣言しておけば、エラー箇所の範囲を狭めやすくなります。それに実装中は型が頭の中に入っていても、席を立って三歩も歩けば忘れます。すべての変数に型を宣言していては面倒過ぎますが、エラー修正に手間取る場合は型を宣言しながらデバッグすると楽になります。特にコレクションの要素の型エラーは追いにくかったので、余程単純な処理でなければ型を宣言しておくといいと思います。

Fn, FnMut, FnOnce 型はクロージャーを示す

API リファレンスに登場する Fn* 型は、クロージャーを示す型です。例えば Fn(usize) -> bool なら、符号なし整数を引数に受け取って真偽値を返すクロージャーを示します。

Fn, FnMut, FnOnce はどれもクロージャーなんですが、それぞれ性質が異なります。大抵は FnMut が使われるので、当初はそれだけ覚えておけばいいと思います。

Fn: 外側のスコープの変数の内容を変更できません。
FnMut: 外側のスコープの変数の内容を変更できます。
FnOnce: このクロージャーは一度しか実行されません。変数の内容は変更できません。

所有権に慣れるまではクロージャーを使わない

特にクロージャーから外側のスコープの変数を扱う場合、所有権の管理がかなり面倒になります。所有権に慣れるまでは、クロージャーの使用はごく簡単なケースに留めておくのがいいと思います。

構造体と列挙体

Clone トレイトを自動導出しておく

構造体（列挙体）を定義するときは、同時に #[derive(Clone)] を記述して Clone トレイトを自動導出（ clone() メソッドを自動的に追加する）しておくといいでしょう。クローンできて困ることはないと思います。フィールドの内容によっては自動導出できない場合もありますが、そのときはがんばって Clone トレイトを実装したりせずに、ひとまず置いて先に進むといいと思います。 Clone トレイトを自動導出できない構造体には、クローンできてしまうとメモリ安全を確保できなくなってしまうフィールドが含まれている可能性が高いと思います。

#[derive(Clone)]
struct Foo {
    ...
}

再帰的な構造体や列挙体を定義したい

自身の型をフィールドに持つ再帰的な構造体や列挙体の定義は、ただ同じ型を指定するだけではできません（ 1.5.0 現在）。例えばこんな感じの構造体です。

struct Person {
    parent: Option<Person>,
    name: String
}

理屈はともかくとして、これは再帰的に扱う型を Box で囲めば定義できます。 Box を使うので、アクセスの手間は増えます。アクセス時は * を適当につけて乗り切ってください。コレクション型など　Box を省略できる型もあり、都度調べてください。

struct Person {
    parent: Option<Box<Person>>,
    name: String
}

ただし、再帰的な構造体、列挙体を定義する前に、本当に必要かどうかを検討すべきだと思います。つい再帰的な構造体を定義したくなりますが、クローン時にやたらとコピーが発生する可能性があって、場合によってはボトルネックになりかねないかもしれません。とは言え最初からパフォーマンスを考えるのも徒労に終わるでしょうから、まずはやってみるといいと思います。列挙体ではわりと必要になると思いますし。

それなら借用を使ったらどうかと考えると思いますが、型定義と生存期間の管理が途端に複雑になります。このようにすれば一応できなくもないです。

struct Person<'a> {
    parent: Option<&'a Person<'a>>,
    name: String
}

大抵のケースでは再帰的な借用の管理に悩むだけ時間の無駄だと思いますので、再帰的な構造や借用をできるだけ使わない方法も考えてみるといいと思います。

ライブラリ

sprintf はどこにある？

format! マクロがそれです。

文字列バッファはいずこ

String がそれです。 String は可変の文字列です。

文字列を結合する

format!

一つの方法は format! です。文字列にしろ数値にしろ大抵のデータを文字列化できますから、とりあえずはこれで済ませておけば楽でしょう。フォーマットについても "{}" だけ覚えておけばなんとかなります。

let hello = "Hello ";
let world = "world!";
let hello_world = format!("{}{}", hello, world);
print!("{}", hello_world);

String::push_str()

もう一つは String::push_str() メソッドで、既存の文字列に他の文字列を追加できます。このメソッドの引数の型は String ではなく &str なので、 String を結合するなら & をつけます。なぜかって？細かいことは後回しです。

let mut hello = "Hello ".to_string();
let world = "world!".to_string();
hello.push_str(&world);

+ 演算子

加えて + 演算子があります。 ~~こちらは結合した新しい文字列を返します。~~ push_str() と同様に引数の型が &str ですので、 String を結合するならやっぱり & が必要です。

let hello = "Hello ".to_string();

// 文字列リテラル &str ならこれで OK
let hello_world = hello + "world!";

// String なら & をつける
let world = "world!".to_string();
let hello_world = hello + &world;

コメントを頂いて勘違いに気付いたのですが、文字列に対する + 演算子の戻り値は左辺の値です。メモリーアロケーションは発生しません。どういうことかと言うと、 + 演算子はこう実装されています。

// Add トレイトで + 演算子を実装できる
impl<'a> Add<&'a str> for String {
    type Output = String;

    #[inline]
    fn add(mut self, other: &str) -> String {
        self.push_str(other);
        self
    }
}

+ 演算子は左辺の値に対して push_str() を呼んでいるだけです。 push_str() との違いは二つ、戻り値があることと、呼び出し時に左辺の値の所有権を譲渡しなければならないことです。とは言え、 push_str() の別名みたいなものですし、そう難しく考えなくてもいいと思います。それに大抵の場合は format! か push_str() を使う方が楽でしょう。

コレクションのクローンに注意

もしかすると誰もこんな勘違いはしないかもしれませんが、クローン前とクローン後のコレクションは参照を共有しません。同じ要素を持っていても、それぞれは独立したコレクションです。つまり、 A という Vec をクローンした B があるとして、 B の要素を編集しても A には影響がない、ということです。

次のコードでは、 vec1 をクローンした vec2 の要素を編集して、それぞれの要素のリストを表示します。

let vec1 = vec![1,2,3,4,5];
let mut vec2 = vec1.clone();
vec2[0] = vec2[0]*2;
vec2[1] = vec2[1]*2;
vec2[2] = vec2[2]*2;
vec2[3] = vec2[3]*2;
vec2[4] = vec2[4]*2;
print!("vec1: ");
for e in vec1.iter() {
    print!("{} ", e)
}
println!("");
print!("vec2: ");
for e in vec2.iter() {
    print!("{} ", e)
}
println!("");

実行結果:

vec1: 1 2 3 4 5 
vec2: 2 4 6 8 10

この通り、 vec2 を編集しても vec1 に影響はありません。どうしてだか私は「 vec2 への操作は vec1 に影響する」と思い込んでしまっていて、それを回避しようとして、データ構造を不要に複雑にしてしまったことがあります。かと言って、コレクションを共有しようとして可変の借用を使うと、それはそれで複雑になるので、慣れないと落とし所を見つけるのが難しいかもしれません。基本的には、新しいオブジェクトを作って操作することを考えるべきなのかもしれません。

イテレーターを探せ

イテレーター以外の、 map とか　filter とか、コレクションの各要素に対して処理を行う他のメソッドを一度は探すと思います。探してませんか？知ってましたか？さすがです。参りました。

そこら辺のメソッドはだいたいイテレーターに実装されています。正確には、イテレーターは Iterator トレイトを実装したオブジェクトですので、この API を探してみてください。難点は、型定義がやたらとややこしそうに見えることでしょうか。とりあえずは、 FnMut という型はクロージャーを指すと覚えておけばなんとかなるかと思います。

スマートポインター（または参照カウンター）

Rust で「何を」変更可能とするかはややこしくて、 mut というキーワードだけでも let mut の変数定義と &mut の可変の借用では意味が異なります。変更可能な値を使い回したい場合、単純に考えれば可変の借用を使えばいいのですが、時にはどうしても、借用に頼ることなく、値への参照をオブジェクト間で共有したい or しなければならない場合があります。しかもそういうときに限って、参照先の値を変更可能にしたいことが多いかと思います。できれば設計を見直すべきですが、それでもやっぱり避けられない場合もあるかと思います。一体どんな状況なのよと聞かれても一般的な例が思いつかない。すみません。

そういうとき、スマートポインター（または参照カウンター）に相当する手段が解決策の一つだったりするかもしれません。で、それはおそらく Rc<RefCell<T>> で実現できます。詳細はこちらが参考になります。

注意しなければならないのは、この種の操作は早い話が「所有権の管理は自分でやれ」ということです。 Rc も RefCell もスレッド間で受け渡しができず、 RefCell は扱い方を誤ると実行時に panic で落ちる可能性があります（その可能性をコンパイラは検出できません）。危険かつ面倒な処理になると思いますが、詳しくはドキュメントを参照してください。

その他

スタックオーバーフローの対処

thread '<main>' has overflowed its stack

このエラーが出たら、メインスレッド <main> のスタックが溢れた（オーバーフロー）ということです。このエラーで頻繁にアプリケーションが落ちる場合は、どこかで関数呼び出しをネストし過ぎてないか、無限ループに陥ってないか、まずソースコードを見直します。

それでも解決しなければ、スタックサイズを拡大する方法もあります。当面はバッドノウハウかもしれませんが、この方法でしか乗り切れない場面もあるかもしれません。

バックトレースを有効にする

環境変数 RUST_BACKTRACE をセットすると、 panic 発生時にバックトレースが表示されます。現時点では RUST_BACKTRACE の値は何でも構わないようですが、 RUST_BACKTRACE=1 としておくと無難そうです。ただ、各所の行番号は表示してくれないようで、わかりやすいとは言えないかも。

バックトレースの例:

thread '<main>' panicked at 'called `Option::unwrap()` on a `None` value', ../src/libcore/option.rs:365
stack backtrace:
   1:        0x109d5e010 - sys::backtrace::tracing::imp::write::he715e18a60aa49cbY7s
   2:        0x109d5d173 - panicking::on_panic::hf85837ce31d02cf7wWw
   3:        0x109d56282 - sys_common::unwind::begin_unwind_inner::h263a8f3a93eff05evas
   4:        0x109d5676e - sys_common::unwind::begin_unwind_fmt::he11604dee4a7c025B9r
   5:        0x109d5c9f7 - rust_begin_unwind
   6:        0x109d7c4b0 - panicking::panic_fmt::hc3363d565c1048da4HJ
   7:        0x109d7befc - panicking::panic::h14af70be4f3d4feaBGJ
   8:        0x109cf0b97 - main::hb74001eb22c0d750Zea
   9:        0x109d5efe2 - sys_common::unwind::try::try_fn::h8880715059644542985
  10:        0x109d5c838 - __rust_try
  11:        0x109d5ee6b - rt::lang_start::hf0f318bf9acb9103hUw

Unity における「カメラ」という考え方

SUZUKI Tetsuya — Thu, 23 Jan 2020 15:46:09 +0000

※この記事は 2014年08月08日に Qiita に投稿したものです。

この内容はきっと他の 3D 系開発ツールでも有用だと思いますが、タイトルを「Unity」と限定したのは、私が cocos2d と Unity しか使った経験がないゲーム開発初級者だからです。許せ。

カメラの「存在」

通常、私たちはテレビやモニター、あるいは携帯型ゲーム機やらスマホなど専用のディスプレイにゲーム画面を映し出して遊びます。私たちにとっては目に見えている画面=ゲームですが、 3D のゲームでは、開発者が用意した 3D 空間の一部しか画面に映りません（どうにか全部表示しても遊びにくくなるだけですよね）。そのため、プレイヤーがゲーム空間を把握する必要のあるゲームでは、主観視点で歩き回れるようにするなり、マップを回転させるなりしてプレイヤーの手助けをします。こうして、私たちは平面のディスプレイを通して 3D のゲーム空間を覗き込みます。このとき、ディスプレイに映し出される光景を切り出す役を担うのが「カメラ」です。 3D ゲームではカメラはプレイヤーの目となり、また手にもなります。手にもなります。大事なことなので（ry

まあ言われてみれば「そんなの当然じゃないの？」と思われるかもしれませんが、 3D ゲームの開発にも映像撮影にも縁のなかった私は、普段から 3D のゲームで遊んでいても「自分はカメラを通してゲーム内のオブジェクトを見ている」という考え方をしなかったので、カメラの使い道になかなか気が回りませんでした。 Unity の入門書は何冊か読んだんですけど、読んだ中ではカメラについてのまとまった解説は見当たらなかったんで、覚えたことをまとめておきます。

ゲーム空間とディスプレイのギャップを埋めるカメラ

例えば、クリックされたオブジェクトを選択状態にしたいとします。クリックされたディスプレイ上の位置（二次元座標）を取得する API はもちろんあります。ですがその座標でゲーム空間内のオブジェクトを指し示せるのかというと……そうもいきません。オブジェクトがどうディスプレイに映し出されようとも、それはあくまでカメラの視点です。ゲーム空間におけるオブジェクトの位置（三次元座標）とディスプレイ上の位置（二次元座標）はまったくの別物です。「ディスプレイ上の座標 (x, y) に表示されてるオブジェクトを取得したいんだけどさあ」と思っても、オブジェクトたちにすれば「私たちがディスプレイにどう映ってるかなんて知りませんよ。カメラさんに聞いてください」と答えるしかありません。

ゲーム空間（三次元） <-> カメラ <-> ディスプレイ（二次元） <-> プレイヤーの目と手（入力デバイス）

具体的な解決方法は後述しますが、このようにゲーム空間とディスプレイの間には座標のギャップがあります。というか間にカメラが入ってるんだから当然と言えば当然ですが、私たちが普段使っている入力デバイス（マウスとかゲーム用のコントローラーとか）も三次元座標を手軽に伝達できるようにはなっていません。ということは、ゲーム空間をディスプレイに表示するのとは逆の方向 -- ディスプレイ上で指定した位置をゲーム空間に関連付ける手段も必要になります。というか間にカメラが入ってるせいでギャップが発生するんだから、これもカメラが解決方法を提供してくれます。

ちなみにディスプレイ上の座標を「スクリーン座標 (screen point/position) 」、ゲーム空間内の座標を「世界座標、ワールド座標 (world point/position) 」と言います。 “ScreenToXXX” や “WorldToXXX” などの名前の API は、これらの座標を変換します。

光線を放つカメラ

カメラの API には、指定した座標に向かって光線を出すメソッドがあります。例えばこうすると、クリックされたゲーム空間内の座標（スクリーン座標じゃないのかって？とりあえずそういうものだと思ってください）に向かって人には見えない怪光線をカメラから打ち出します。ビビっと。

Ray ray = Camera.main.ScreenPointToRay(Input.mousePosition);

“Ray” とは「光線」の意です。初めてこのコードを見たときには「何の役に立つんだこんなもの？」と思ったのですが、ちょっと想像してみてください。カメラから出力された光線は、途中で何らかのオブジェクトにぶつかります。そのオブジェクトを「プレイヤーがクリックした（い）オブジェクト」とみなせば、「プレイヤーがクリックしたスクリーン座標から、ゲーム空間内のオブジェクトを指定する」ができるようになるわけです。光線と衝突したオブジェクトを検出するコードは探せば出てきますので、そちらをどうぞ。

さて今の説明では、最初にゲーム空間内の座標をプレイヤーが指定した前提で進めています。現実には、プレイヤーがクリックできるのはスクリーン座標です。スクリーン座標と世界座標の違いは「 Z 座標（奥行き）の有無」ですね。スクリーン座標は二次元座標ですから Z 座標はありません。ですが、「カメラもオブジェクトの一つである」ことを思い出してください。スクリーン座標がカメラのレンズ上の点であるならば、ここに「カメラからの距離」を加えれば、スクリーン座標を（世界座標を示す）三次元座標に変換できます。上のコードでは「カメラからの距離」を無視してしまっていますが（ゼロ距離とみなしています）、まあ問題が出たら調整すればいいと思います。

前節で「カメラはプレイヤーの手にもなる」とか「ゲーム空間とディスプレイのギャップを埋める」などと書きました。それらの機能の一つがこれです。

立体感の有無

カメラによる「空間の見え方」は一つではありません。デフォルトの設定では、カメラは私たちの目に自然に映るような立体感を持った画像にしてくれます。これを「透視投影モード」と言い、カメラの設定項目に "Perspective" とあるのがそうです。

これを、もう一つの設定項目である "Orthographic" にすると、立体感を消し去ったような画像にしてくれます（手元に Unity を動かせる環境があるならさっさと試してみるといいでしょう）。立体感のない、つまり距離感のない画像がどんなものかというと、俯瞰図をイメージすると早いです。

3D 空間を歩き回るゲームなんかだと、俯瞰図って必ず出てくるでしょう？簡単なものでは街並みやダンジョンの全体マップだとか、ちょっと形が変わったものだとレーダーも俯瞰図の一種です。立体感を消すだけで多種多様な見せ方ができるのが面白いですね。

見せたいものしか映さないカメラ

少し前の立体感の設定の説明で、俯瞰図を例に出しました。全体マップとかレーダーとか、確かに俯瞰図にすれば手軽に実現できそうです。と思って平行投影モードにしてみると、なんだかごちゃごちゃした画面ができてしまいませんでしたか？何せすべてのオブジェクトを俯瞰図にしているんですから当然です。求める画面を作るには、余分なオブジェクトを消す……というか、その逆の「見せたいオブジェクトだけを映す」が必要になります。例によって詳細は「レイヤー」とか "Culling Mask" でぐぐってください。

実際にはカメラとオブジェクトの双方に設定が要りますが、「見せたいオブジェクト」と「立体感の有無」の組み合わせは強力です。特に人以外のレイヤーのオブジェクトが映り込んだ映像には誰もが心惹かれるものですよね。……あ、いわゆる心霊なんとかってやつですよ。

カメラは何台でも用意できる

ここまで書いておいて今更ですが、カメラもオブジェクトの一つであり、複数台のカメラをゲーム空間内に配置できます。これも「そんな当然のことわかってるよ」と思われるでしょうけど、多重度の意識は大事ですよね。

デフォルトではメインカメラ一台のみが用意されています。目まぐるしく視点が切り替わるようなゲームでは、視点ごとにカメラを用意しておいて、必要に応じてカメラを切り替えればよさそうですね。

カメラを回転させるために覚えておくこと

Unity （ API じゃなくて開発ツールの方）では、カメラの回転は “Rotation” という項目で、 “x” “y” “z” の三つの値で表されます。これをスクリプトで制御しようとすると、 "Quaternion" （クォータニオン）という値をカメラの “rotation” プロパティにセットすることになります。クォータニオンにも “x” “y” “z” というプロパティがありますが、これに “Rotation” の項目と同じ値をセットしても思うようには動きません。

スクリプトによるカメラ操作のとっかかりとしては、次の点を押さえておけばいいと思います。まあ私も全然詳しくないです。

オブジェクトの回転（姿勢）はクォータニオンという概念で表される。
開発ツールで設定できる “Rotation" の値とクォータニオンの値は同一ではない。
“Rotation” の値をクォータニオンに変換するには、 Quaternion.Euler 関数を使えばよい。

リソースオブジェクトについて

SUZUKI Tetsuya — Thu, 23 Jan 2020 15:43:54 +0000

※この記事は 2014年12月17日に Qiita に投稿したものです。 crypto に関する記述は Erlang 17.3 時点で、現在の最新版では仕様が変わっています。

リソースオブジェクトとは

NIF で使われるデータ型の一つにリソースオブジェクトがあります。リソースオブジェクトとは任意のデータをラップして Erlang との橋渡しをするデータで、主に構造体へのポインタをラップするのに使われます。 Erlang レベルにリソースオブジェクトを渡す場合は、リソースオブジェクトを持つリソース項を生成して渡します。 Erlang レベルからリソースオブジェクトを受け取るには、受け取ったリソース項からリソースオブジェクトを取り出します。ややこしいですね。

リソース項はなぜか Erlang レベルではバイナリ型とみなされますが (is_binary/1 が真になる) 、内容は隠蔽されて見えなくなります。また、ラップするデータごとにリソース型 (resource type) を用意しておくことで、引数として受け取ったリソースオブジェクトを区別でき、不正な型のデータが NIF に渡ってしまうのを防げます。

リソースオブジェクトを使わない場合

NIF レベルで使うデータを Erlang レベルに渡したい場合、数値や文字列のような単純なデータなら、ストレートに Erlang 項に変換すれば簡単です。値の妥当性検査も簡単です。

問題はバイナリや構造体のような検査しにくいデータを Erlang レベルに渡す場合で、データをバイナリ項で表したり、ポインタ値を整数項にするなどで Erlang レベルに露出させてしまうと VM が落ちる原因になる可能性があります。

Erlang の項はすべて不変ですので項の内容は変更できませんし、直ちに問題が起こるわけではありません。問題は、項を NIF レベルで処理するときに起こります。

例えば crypto モジュールがこの問題を抱えています (抱えているっつーかほったらかしっつーか) 。対話型シェルで次のコードを入力すると VM が落ちるはずです。 (17.3 で確認)

$ erl
Erlang/OTP 17 [erts-6.2] [source] [64-bit] [smp:12:12] [async-threads:10] [kernel-poll:false]

Eshell V6.2  (abort with ^G)
1> {sha256, C1} = crypto:hash_init(sha256). 
{sha256,<<103,230,9,106,133,174,103,187,114,243,110,60,
          58,245,79,165,127,82,14,81,140,104,5,155,171,
          217,131,...>>}
2> C2 = list_to_binary(lists:reverse(binary_to_list(C1))).
<<0,0,0,32,0,0,0,0,0,0,0,0,0,0,19,204,0,0,0,1,17,116,12,
  216,0,0,0,1,0,...>>
3> crypto:hash_update({sha256, C2}, <<123>>).
Segmentation fault: 11

これでなぜ落ちるのかというと、 hash_update/2 が受け取ったバイナリが、 OpenSSL 内部で使われる構造体のデータとしてストレートに OpenSSL の関数に渡ってしまうからです。これを防ぐには引数の内容をチェックするか、そんなことはめんどくさいし完璧にはできないので、リソースオブジェクトを使うと安全です。

前述の crypto モジュールでは、 HMAC の関数でのみリソースオブジェクトが使われています。 hmac_init/2 を実行すると、表面上は空のバイナリに見えるデータが返ってきます。

11> C = crypto:hmac_init(sha256, <<>>).                   
<<>>
12> is_binary(C).
true

リソースオブジェクトの操作

メモリ管理

リソースオブジェクトのメモリ管理は参照カウントで行われます。 Erlang 項ではないため GC には回収されません。

     Erlang レベル                           NIF レベル
<---------------------->       <---------------------------------->
リソース項 (ERL_NIF_TERM) <----> リソースオブジェクト <----> 任意のデータ
    GC に回収される                 参照カウント

リソースオブジェクトから生成したリソース項、これは Erlang のオブジェクトなので GC に回収されます。
リソース項が解放されると、リソース項が保持していたリソースオブジェクトへのオーナーシップが取り消されます。要は参照カウントが一つ減ります。
リソースオブジェクトは参照カウントが 0 になると解放されます。
リソースオブジェクトが解放されるとデストラクタ関数 (enif_open_resource_type() で指定します) が呼ばれ、ラップされていたデータの解放処理が行われます。

参照カウントの増減するタイミングはこうです:

リソースオブジェクトを生成すると (enif_alloc_resource) 、カウントは 1 になる
リソース項を生成すると (enif_make_resource) 、カウントが 1 増える
enif_keep_resource を呼ぶと、カウントが 1 増える
enif_release_resource を呼ぶと、カウントが 1 減る
リソース項が GC に回収されると、カウントが 1 減る

増減のタイミングはいくつもありますが、基本的には「 alloc/keep したらどこかで release する」です。もちろん、解放したくなければ release する必要はありません。

リソース型を生成する

リソースオブジェクトの準備として、まずはリソースオブジェクトの内容を区別するためのリソース型を enif_open_resource_type で生成しておきます。 rebar で NIF のテンプレートを指定してプロジェクトファイルを作ると、リソース型を生成するコードも含まれます。

こんな感じ。 enif_open_resource_type は特定のコールバック (load, reload, upgrade) でのみ呼べます。

static ErlNifResourceType *rt;

static int
on_load(ErlNifEnv* env, void** priv_data, ERL_NIF_TERM load_info)
{
  ErlNifResourceFlags flags = ERL_NIF_RT_CREATE | ERL_NIF_RT_TAKEOVER;
  rt = enif_open_resource_type(env, NULL,
      "resource_name",   /* リソース名 */
      &resource_cleanup, /* リソースの解放処理を行う関数 */
      flags, NULL);
  if (rt == NULL)
    return -1;

  return 0;
}

リソースオブジェクトを生成する

リソースオブジェクトの生成から破棄までが一つの関数内で完結するような単純な処理であれば、だいたい次の流れで書けます。

リソースオブジェクトを生成する (enif_alloc_resource) -> 参照カウントは 1
リソース項を生成する (enif_make_resource) -> 参照カウントは増えて 2
リソースオブジェクトの参照を減らす (enif_release_resource) -> 参照カウントは 1 。リソース項が GC に回収されると 0 になる
リソース項を返す

次のコードはドキュメントに掲載されているサンプルです。

{
    ERL_NIF_TERM term;

    /* リソースオブジェクトを生成する */
    MyStruct* obj = enif_alloc_resource(my_resource_type, sizeof(MyStruct));

    /* 構造体を初期化する ... */

    /* リソース項を生成する */
    term = enif_make_resource(env, obj);

    if (keep_a_reference_of_our_own) {
        /* 'obj' を静的変数に代入するなら release の必要はない */
    }
    else {
        /* リソースオブジェクトの参照カウントを減らす */
        enif_release_resource(obj);
    }
    return term;
}

これまでリソースオブジェクトがリソースオブジェクトがーと連呼してきましたが、リソースオブジェクトそのものを示す型は NIF では登場しません。 enif_alloc_resource が返すのは、指定したサイズのメモリブロックへのポインタ (void *) です。実行中の参照カウントの値を知る方法もありませんので、参照カウントではまるとデバッグが面倒です。

リソース項からデータを取得する

リソース型を指定し、 enif_get_resource で取得します。指定のリソース型以外の型はすべて弾かれます。 Erlang レベルではリソース項を改竄できませんから、これで引数にどんな値が来ても大丈夫です。

static ERL_NIF_TERM my_func(ErlNifEnv* env, int argc, const ERL_NIF_TERM a
rgv[])
{
  my_resource *data;
  if (!enif_get_resource(env, argv[0], my_resource_type, (void **)&data))
    return 0;
    ...
}

まとめ

君も crypto モジュールを修正すれば Erlang/OTP に contribute できるチャンス！...だと思いますがどなたかどうですか。私はめんどくさいのでいいです。

OCaml で return 相当の処理を実装する

SUZUKI Tetsuya — Thu, 23 Jan 2020 15:36:03 +0000

※この記事は 2016年02月15日に Qiita に投稿したものです。

OCaml には return 文（または式）がありません。 OCaml の関数は最後に評価された式の値を戻り値とします。ですので、戻り値に関しては return が不要なのですが、関数の実行の中断（脱出）もできません。

ですが、 Jane Street Core に含まれる with_return 関数が同等の処理を実装しています。このソースをいきなり読むのは初級者には難しかったんで、実現したい仕様からコードを逆算して考えていきます。なお、以降のコードは Core に依存しません。

まずは、関数の使い方です。次のような使い方を想定しています。ソースは common.mli のコメントから、 Core に依存しない形に修正しています:

let find f l =
  with_return (fun r ->
    List.iter (fun x -> if f x then r.return (Some x)) l;
    None
  )

これは List.find の実装例です。実際の Core.Std.List.find は with_return を使っていませんので、あくまで一例です。 return を含める処理をクロージャーで書いて、それを with_return に渡します。 List.find は再帰で簡単に書けますが、 return のある言語に慣れている人にとってはこちらのコードの方がわかりやすいかもしれません。

では、 with_return の実装方法を考えていきます。その前に、使い方を示しておいてなんですが、上の例では r.return のように、 return 関数はレコード r のメンバーです。でも r は必要なのか？ return 関数のみを渡せばいいんじゃないのか？と私は思ったので、その使い方を想定してみます:

let find f l =
  with_return (fun return ->
    List.iter (fun x -> if f x then return (Some x)) l;
    None
  )

多少シンプルになりました。これで考えてみます。

with_return は引数に関数を一つ受け取りますから、こんな感じで始まりますね。

let with_return f = ..

次に、 f に渡す return 関数を考えます。 with_return なんてクッションを置かずに一つの関数で return を済ませられればいいのですが、さすがに無理です。仕方がないので f 内で return を使ってもらいます。 return は関数内で実装するとして、こんな感じです:

let with_return f =
  let return value = .. in
  f return (* あとはなんとかして戻り値を処理したい *)

今度は、 return を呼んだら関数 f を脱出する処理です。そんな処理を書けるのか？と言えば、そこは例外を利用すればいけます。例外を上げれば f を脱出できますから、その例外を捕捉すればいけそうです。例外は専用の型を別途用意するとします:

exception Return of 'a

let with_return f =
  let return value =
    raise (Return value)
  in
  try f return with
  | Return value -> .. (* 戻り値の処理 *)
  | exn -> raise exn (* 他の例外だったらスルーしとこう *)

List.find の例くらいなら問題なくいけそうな気が...コンパイルできない。どうやら exception Return of 'a はコンパイルできないようです。

# exception Return of 'a;;
Error: Unbound type parameter 'a

型変数 'a が宣言されていないとのエラーですが、例外に型変数は指定できません。 OCaml の例外の型は exn で、ユーザー定義の例外は exn の型コンストラクタとして扱われます。偉そうに言ってますが、私はナチュラルに間違えました。

exn は型変数を持たないので、 exception Return of 'a の 'a は無効です。定義するなら、 exception Return of string のように具体的な型を指定する必要があります。関数の性質上、特定の型に絞ると使いにくいので、この方法ではだめそうです。

これを解決するにはどうするか。例外のデータ型に型変数を指定できないなら、どうにかして戻り値の型ごとの例外を定義してはどうでしょう。でも、

exception Return_string of string
exception Return_bool of bool
exception Return_int of int
..

let with_return_string f = ..
let with_return_bool f = ..
let with_return_int f = ..

などと、型ごとに例外と関数を定義するのは面倒ですし、 with_return を内部で使う関数の型を抽象化しにくくなります。ここでの例で言えば、

let find f l =
  with_return (fun return ->
    List.iter (fun x -> if f x then return (Some x)) l;
    None
  )

'a list -> ('a -> bool) -> 'a option としたい find 関数の型が、次のように型別の with_return を使うことによって、

let find f l =
  (* 戻り値は文字列 *)
  with_return_string (fun return ->
    List.iter (fun x -> if f x then return (Some x)) l;
    None
  )

string list -> (string -> bool) -> string option のように限定されてしまいます。仕方がないから find も型ごとに find_string, find_bool...と用意するとなると、さすがにこれでは使いにくい。

できるならば、 with_return の呼び出し箇所に応じて、戻り値の型に合わせた例外を自動的に定義したい。そんなことが可能なのかと言えば、できるらしいです。局所的抽象型 (locally abstract types) という仕様で、関数内でのみ有効な抽象型を扱えます。ただし関数内では例外を定義できませんので、モジュール定義と組み合わせます。つまり、（戻り値の型を含む）例外を含むモジュールを関数内で定義する、ということです。わからない？ごもっともです。要するに次の形で書けます:

let with_return (type value) f = 
  let module M = struct
    exception Return of value
  end in
  let return value =
    raise (M.Return value)
  in
  try f return with
  | M.Return value -> value
  | exn -> raise exn

(type value) という謎の記述が局所的抽象型です（ OCaml 3.12 からの機能で、全然最新ではないんですが）。これは引数ではなくて、関数内でのみ有効な抽象型 value の宣言です。 value という特定の型があるわけではないです。

前述のように、関数内では例外を直接定義できません。そのためモジュール定義と組み合わせたのが

let module M = struct
  exception Return of value
end in

のコードです。この struct は何なのか？モジュール定義で書くアレじゃないのか？そうです、モジュールの定義（というか生成）です。ここで戻り値用の例外 Return を含む新しいモジュール M を生成してます。実はモジュールはファーストクラスオブジェクトで、値として操作可能、動的に生成できます（詳しくは RWO の First Class Modules を参照してください）。静的型付けの OCaml で動的にモジュールを生成ってなに？と混乱しそうだったら、モジュールというものを深く考え過ぎているのかもしれません。静的に型付けすることと、動的に（実行時に）モジュールオブジェクトを生成するのは、それぞれ別の処理です。

ややこしい説明は続きます。そのモジュール定義に含まれた例外で抽象型 value を指定していますが、先を見た方がわかりやすいでしょう。例外 Return を使っている箇所はここです（引数の value と type value は名前が同じですが、前者は値、後者は型で、名前空間が異なる別のデータです。同じ名前を使う必要はありません）:

let return value =
  raise (M.Return value)

引数（ユーザーが戻り値とする値）を例外 Return でラップして、例外を上げます。従って引数 value の型は、局所的抽象型の value です。これでどうなるのかと言うと、「実行時に戻り値の型用の例外を含むモジュールが生成され、型推論時に例外の型が決定される」とすればいいんでしょうが、説明されるよりコードを理解する方が早いかもしれませんね。

これで一応の機能はできました。これ以降ですが、 Core の実装では with_return から渡される関数 return の呼び出しを with_return の実行内に制限しています。 Core に依存しない形にしてみると、こんな感じです:

let with_return (type value) f = 
  let module M = struct
    exception Return of value
  end in
  let is_alive = ref true in
  let return value =
    if not !is_alive then
      failwith "already returned";
    raise (M.Return value)
  in  
  try 
    let value = f return in
    is_alive := false;
    value
  with exn ->
    is_alive := false;
    match exn with
    | M.Return value -> value
    | _ -> raise exn

with_return に渡す関数の呼び出し後に return 関数を呼び出すとエラー（例外だけど）にします。そうする理由は with_return の実装の隠蔽でしょうか。万が一 return が with_return 外に持ち越されてしまった場合に思わぬ箇所で例外が上がってしまうとか、あるいは例外 Return がローカルなモジュールに定義されているので、ユーザーからは例外 Return を捕捉する方法がないとか。特にコメントが書かれていませんので、私の OCaml レベルではわかりません。ただ、 Core でも failwith 使っとくんだなとはわかりました。

さて、最後は型です。これまでの実装だと、 with_return の型はこうです。

val with_return : (('a -> 'b) -> 'a) -> 'a

('a -> 'b) が return 関数の型です。ここなんですが、もちろん return 関数が取る引数 'a は戻り値として渡す型です。では、 return 関数の戻り値 'b は何でしょう？ややこしいようですが、例えば return true という式があったら、その戻り値は何でしょうか。 bool ではないです。というのは、 return 関数は必ず例外を上げるからです:

let return value =
  if not !is_alive then
    failwith "already returned";
  raise (M.Return value)

return 関数で最後に評価されるのは、例外を上げる raise 関数です。 raise の型は exn -> 'a で、 return 関数の戻り値もここに関係します。で、この戻り値 'a は何なのか？

例外を上げてしまいますから、 raise から戻り値は返ってきません。それなら unit にしてもよさそうに見えますが、 'a であるのは対になる式と型を合わせるためかと思います。例を出しますと、 val bool_of_string : string -> bool はこう実装できます:

let bool_of_string = function
  | "true" -> true
  | "false" -> false
  | _ -> raise (Invalid_argument "bool_of_string")

上二つのパターンマッチ後の値が bool であるのに、最後のパターンマッチが raise で終わっても問題ないのは、 raise の型が exn -> 'a だからです。この場合ですと、'a は bool に置き換えられます。もし raise の戻り値が unit であれば、実際には使われない適当な値を書く必要が出てきます。 'a のおかげで余計なコードを書かなくて済むというわけです。

というわけで話を return 関数に戻しますと、 ('a -> 'b) の 'b は raise の戻り値です。深く考える必要はない..かもしれませんが、こういう手続き的なコードを書くとしたらどうなるでしょうか？

(* 実用的な意味はありません *)
let map f l =
  with_return (fun return ->
    if List.length l = 0 then
      return None; (* ポイント *)
    let map = List.map (fun x ->
      match f x with
      | None -> return None
      | Some x' -> x') l
    in
    Some map
  )

この関数の私が意図した型は

('a -> 'b option) -> 'a list -> 'b list option

です。ところが、このコードを型注釈なしにコンパイルすると、

('a -> unit option) -> 'a list -> unit list option

こう推論されます。なぜ unit になるかと言えば、最初の return 呼び出しの戻り値が unit だからです。従って次の return も unit 、従って x' も unit であり、従って f は ('a -> unit option) と推論されます。これでは困るので、次のように型注釈をつけてコンパイルしてみます。

let map f l : ('a -> 'b option) -> 'a list -> 'b list option = ..

するとコンパイルエラーが出ました。

Error: This expression has type unit list option
       but an expression was expected of type
         ('a -> 'b option) -> 'a list -> 'b list option

まあ、そりゃそうですね。最初の return 呼び出しの戻り値が unit であることに変わりませんから。と、このように複数箇所で return を使う場合は、戻り値を揃えないといけません。

しかし、これは少々トリッキーな方法で解決できるようです。とは言え Obj.magic のようなチートではなく、高ランク多相とかランクN多相とか言われる型表現を、多相レコードで表します。 Core のコメントには、こう書きたいんだけど ML の表現力では無理だから多相レコードを使ったとあります。

(* エラーですよ *)
val with_return : 'a. (('a -> ('b. 'b)) -> 'a) -> 'a

'a. と 'b. のピリオド付き型変数は、型変数の宣言です（この文法は存在しますが、このようには書けません）。何の意味が？というと、型変数のスコープを指定できます。というかしたいんだけど OCaml ではできないので、あくまで疑似コードです。

val with_return : 'a. (('a -> ('b. 'b)) -> 'a) -> 'a
                   |            +---+              |
                   |             'b                |
                   +-------------------------------+
                                 'a

これがどう return に影響すると言うのか？ return の型は ('a -> 'b) でした。 OCaml では（他の言語について詳しくないのでこういう書き方をしてます）、型変数は関数の実装全体で有効です。ですので、一旦 'a と 'b が決定してしまえば、残りの return 呼び出しも同じ型とみなされます。しかし上の宣言が有効だとすれば、 'b の有効範囲は return の戻り値に限定されます。 'b は関数の型には影響せず、 return の呼び出し箇所ごとに決定されるわけです。従って前述の例のように、 return の戻り値が unit である箇所とそうでない箇所があっても、それぞれで 'b が決定されるので問題ないということになります。おそらくこれを高ランク多相とかランクN多相と言うのだと思いますが、 OCaml ユーザーにはプログラミング in OCaml の「 12.5.4 多相メソッド」の項が参考になるかと思います。

さて、繰り返したように上記の仕様は OCaml で実装できないのですが、多相フィールドを持つレコードを使うとなんとかなります。それが次の定義です。

type 'a return = { return : 'b. 'a -> 'b }

'b. 以外のコードは特に問題ないでしょう。問題は return : 'b. 'a -> 'b の部分です。 'b. が型変数のスコープだと言われても、それがどうこの定義に関係するのか？

これまでに登場した return の型は 'a -> 'b でした。ここでもそれは変わりません。ところが、 'b は左辺に登場しません。 'b は return 関数呼び出しの文脈でのみ具体化され、レコードに影響しません。多相メソッドとも言い、繰り返しますが、詳しくはプログラミング in OCaml の「 12.5.4 多相メソッド」の項が参考になるかと思います。

ともかく、この多相フィールドを使うことで、 'a. (('a -> ('b. 'b)) -> 'a) -> 'a のような型変数のスコープを用意できます。というわけで、 'a return 型は return 関数を持つレコードで、 'a は return 関数に渡す戻り値の型です。そして、最終的に with_return 関数の型はこうなります。

val with_return : ('a return -> 'a) -> 'a

以上です。まさか with_return 関数一つに、局所的抽象型、ファーストクラスモジュール、多相フィールドと、濃い仕様がいくつも詰まってるとは思いませんでした。 Core を使う分にはここまで把握しなきゃならないことはないと思いますので、臆せず OCaml と Core にチャレンジしていただければと思います（なかなかそんな人いないか..）。

最後に、実際のコードを引用しておきます。途中で参照されている Exn モジュールは Core の API ですので、そこだけ raise に置き換えれば Core 非依存にできます。 OCaml レベルを上げたければ、この関数に頼らない方がいいんじゃないかなと思います。

type 'a return = { return : 'b. 'a -> 'b }

let with_return (type a) f =
  let module M = struct
    (* Raised to indicate ~return was called.  Local so that the exception is tied to a
       particular call of [with_return]. *)
    exception Return of a
  end in
  let is_alive = ref true in
  let return a =
    if not !is_alive
    then failwith "use of [return] from a [with_return] that already returned";
    Exn.raise_without_backtrace (M.Return a);
  in
  try
    let a = f { return } in
    is_alive := false;
    a
  with exn ->
    is_alive := false;
    match exn with
    | M.Return a -> a
    | _ -> raise exn

イチから始める OCaml

SUZUKI Tetsuya — Thu, 23 Jan 2020 15:33:03 +0000

※この記事は 2017年03月28日に Qiita に投稿したものです。

「ゼロから始める OCaml」の続きです。元々は「やっぱり環境構築は無視できない道かなあ」と思っていたんですが、 Wandbox が Ocaml 、おっと OCaml だった OCaml に対応した (しかも Jane Street Core まで！) こともあり、環境構築は他のサイトなり記事なりを参考にしてもらうとして、 Ocaml 、おっと OCaml だった OCaml を始めたときに気になるであろうポイントをつつきたいと思います。

無料で読めるオススメのサイトはありますか？

なんだかもう恐ろしい経歴の方々が実用視点で執筆された Real World OCaml があります (紙の書籍も出てます) 。よくも悪くも Core に大きく依存する内容で Wandbox と相性がよいです。

英語がきつい？ Google 翻訳にかけると恐ろしいクオリティで日本語でおｋ。人力の和訳が必要なくなるレベルなんじゃないかな、これは...

関数の型の読み方

OCaml の関数の型は "a -> b -> c" の形式で表されます。最後の "->" が戻り値です。 "a -> b -> c" であれば、引数 a, b を渡すと c の型の値が返ってきます。

関数の戻り値の型が期待と違う

前節で関数の型は "a -> b -> c" の最後の c が戻り値だと触れましたが、引数の数を間違えると c になりません。部分適用と言って、引数の数が満たされなくてもエラーにならないのではまりやすいポイントです。想定外の型エラーでビルドに失敗したら、該当の箇所の引数の数を確認してみましょう。

総称型の読み方

'a t という型は、 Java や TypeScript や Swift で言う総称型に相当します。 'a t なら t<a> です。アポストロフィ ' がつくのが型変数です。

`'a` とか `t` とかの 1 文字変数の意味

OCaml の型名は 'a とか t などの 1 文字の変数がよく使われます。これらの変数名は何の略語かと言うと、

型変数 'a: ML 系の言語では a, b, c... とアルファベット順に続くのが慣習のようです。もちろん名前を付けたほうがわかりやすいので、そこはお好みで。
型 t: type の略です。 Module.t という型があったら、それは Module モジュールに所属する型 t を表します。

です。慣れないうちはわかりにくいかも。

ラベル付き引数とオプショナル引数

関数の引数には名前 (ラベル) をつけることができます (Swift にもありますね) 。型宣言だと引数の前にある f: がラベルです。注意すべきは、引数にラベルを付けて関数を呼び出す場合は ~ をつけないといけません。関数 f の型が x:int -> y:int -> int だったら、コードは f ~x:1 ~y:2 と書きます。

ラベルの前に ? があれば、それはオプショナル引数と言って、省略可能な引数です。詳しくはググるか本を読むかしてください。

コードの実行順序

OCaml は型推論のある強い静的型付けの言語です。静的型付けと言えば Java や Haskell 、最近ですと Swift や TypeScript を思い浮かべる方が多いかと思います。これらの言語は宣言の順序にわりと融通がきいて、型やクラスの宣言の場所や順序はユーザーに一任されていることが多いです。

「 OCaml も静的型付けの言語ですからそうだろう」と思いがちですが、実は OCaml のコードは 上から順に 評価されます。いいですね、 上から順に です。次のように、依存する関数をあとから書いたコードはコンパイルできません:

(* 内容は適当 *)
let f x = g x
let g x = x

正しくはこのように書きます。スクリプト言語みたいですね。

let g x = x
let f x = g x

相互に依存する型なり関数なりを書きたい場合はどうするのかって？ and で定義をつなぎます。詳しくは各自調べてください。

ちなみに、関数に渡す引数の評価順序は不定です。関数 f を f x y z と呼び出したからと言って、引数の式が x, y, z の順に評価されるとは保証されません。

エントリーポイント

他の静的型付け言語だと main が一般的なエントリーポイント (最近はマイクロソフトの長音付けルールを参考にしてます) ですが、 OCaml では特別なエントリーポイントはありません。トップレベルに書いた式が 上から順に 実行されます。

ただし、トップレベルと関数定義内の式の文法は少し違い、区切り記号に ; だけでなく悪名高い ;; も使われます。ただし ;; は大抵の場合で省略可能で、言われるほど目にする機会はないと思います。私も滅多に書きません。

トップレベルに式を書く際に ;; を省略する方法は、式の値を let _ = .. と変数に代入するか、 let () = .. のように unit とパターンマッチさせます (もちろん、式の値が unit でなければ型エラーです) 。ちょっと面倒なバッドノウハウですね。

よければ OCaml のエントリポイントも参照してください。

`;;` の意味

上で触れたキモさ抜群の ;; ですが、これも上で触れましたが、トップレベルの式には文法上必要な記号です。と言うのは、関数式とトップレベルの let 式に終端記号がないからです。

例えば次のようにエントリーポイントを書きたいとします:

let main () =
    (* 適当 *)
    f ()

main ()

このとき、最後の main () はどういう扱いになるのか？ OCaml の文法は改行に意味がないので、 f () にくっついて

f () main ()

という式に解釈されてしまいます。

それなら式の区切りに使う ; でどうでしょうか:

let main () =
    f ();

main ()

やっぱり改行に意味はないので、このように解釈されます:

let main () =
    f ();
    main ()

main () が main 関数内で呼ばれることになります。再帰関数に見えますが、 OCaml では let rec で始めないと再帰関数として扱われませんので、それはそれでエラーです。この例はたまたま再帰の形になってエラーになりますが、エラーにならない場合もあり、はまりポイントになってしまうことがあります。バッドノウハウ以外の何物でもありませんが気をつけましょう。

そういうわけで、トップレベルの終端記号である ;; を使えば問題は解決します。こうです:

let main () =
    f ()
;;

main ()

ただし、連続する let 式なら ;; は省略可能です。こう書けます:

let main () =
    f ()

let () = main ()

ちなみに let 式に end のような終端記号を必須にすれば ;; は不要になりますが、 end のないコードは快適でして、ほぼ省略可能な ;; を消すメリットは薄かったりします。

こればかりはキモいけど仕方ないかもしれませんね。

Wandbox で Core を使う

Wandbox が OCaml + Core に対応したことで、わざわざ環境構築しなくてもさっと試せるようになりました。 Core を使う場合はこうします:

"Jane Street Core" のチェックボックスを有効にする
コードの先頭に open Core.Std を書く

これで Core のモジュールを使えるようになります。 Core は OCaml の付属ライブラリのモジュールを同名のモジュールで置換するので、例えば List と書くと Core.Std.List が参照されます。

ただし、置換されるモジュール名や関数名は同じでも、 Core の API は引数のルールが OCaml 付属の API と違います。 Core の特徴は、

1 モジュールにつき中心的な型は 1 つで、 t という名前で定義される
第 1 引数の型はだいたい t
ラベルをよく使う
多相バリアントをよく使う
モジュール名の規則は "Foo_bar_baz" (文法上、先頭は大文字でないといけない)

といったところです。最後のモジュール名などは「やっぱ OCaml の文法キモい」という悲鳴が聞こえますが、私なんかは「 CamelCase だと略語を大文字と小文字のどちらかにするかを考えるのが面倒くさい。 HTTP なのか Http なのかどっちがいいんだ」と思っちゃったんで、他の言語で例を見なくても "Foo_bar_baz" でいいじゃない、で済ませてます。

オブジェクト指向について

OCaml の "O" は元々 "Objective Caml" の "O" であり (現在は略語ではない一単語の "OCaml" に改名されています) 、関数型とオブジェクト指向のハイブリッドでコードを書けます。
もちろん OCaml の書籍でもオブジェクト指向について結構な量のページを割かれているので、普段オブジェクト指向言語を使っている人はまずそこから始めてみることが多いかもしれません。

しかし、実際は ~~実際は大半のユーザーがオブジェクト指向を使ってないと思います。~~ 大半の状況でオブジェクト指向を使わなくても大丈夫だと思います。決して OCaml のオブジェクト指向の出来が悪いのではなく、理由は簡単です。オブジェクト指向って 意外と必要ない からです。必要ない理由はめんどくさいので割愛します (コード書くうちにわかるでしょ) 。オブジェクト指向のコーディングを覚えなくても全然問題ないので、参考書の該当の章は飛ばしてもいいと思います。

ファンクター難しそう

強力かつ複雑な、ファンクターという機能があります。ファンクターを簡単に言うと、コードを抽象化して大幅に無駄を減らせる (かもしれない) 機能です。なんですが、学習したてだとしばらくは必要ないはずです。まったく知らなくても問題ないです。「ここらへんは重複する処理が多くて抽象化できそう、でもやり方がわからない」と何度も痛感したら学ぶか、もしくは脳筋コピペで済ませてもいいと思います。余裕ができたらファンクターに取り組んでみましょう。ひとまずは動けばいいんです、動けば。

私は Real World OCaml や日本語書籍も含めて読んでもなかなかわかりませんでした。「やっぱ難しいんだ...」などとあきらめないで！というか、「最初からファンクターがわからなくてもなんとかなるんだ」とか「おいそこのレビュアー、俺にファンクターを教える権利をやろう」とか、ポジティブに前向きに考えていただけたらと思います。

ガチで取り組むなら何から始めればいい？

私も OCaml での業務経験はさほどないのであくまで個人的な意見ですが、コードを書く前にビルド環境の構築をおすすめします。

幸い、よくも悪くも OCaml ユーザーは世界中に大多数存在するとは言えず、ライブラリやツールの候補も多くありません (しかし、メジャーなものはいずれもハイクオリティです) 。というか余程のヘビーユーザーでなければほぼ一択じゃないでしょうか。最低限次のツールを揃えれば大丈夫だと思います。

パッケージ管理に OPAM
ビルドに OMake
非力な組み込みライブラリを補助するライブラリ。とりあえず Core を使っておけば間違いはないです。でかいのが難点。

他にあるといいもの:

生産性を上げるために OCamlSpotter
足りないライブラリを作る気合い
(ﾟ∀ﾟ)人(ﾟ∀ﾟ)ﾅｶｰﾏ

がんばってください！

OCaml のエントリポイント

SUZUKI Tetsuya — Thu, 23 Jan 2020 15:30:00 +0000

※この記事は 2014年11月04日に Qiita に投稿したものです。

以前「ゼロから始める OCaml」という記事を書いたのですが、その中で “Hello, world!” と出力するコードを例に挙げました。このコードは対話環境 (ocaml コマンド) に入力しても、ファイルに保存してコンパイルしても、どちらでも無事に実行されます。

let () = Printf.printf "Hello, world!\n"

let () = は let _ = としてもOKです。いずれにせよ、 let () = から始まるこの式はエントリポイントなわけですね。

しかし OCaml のコードを書いていると気が付きますが、 let () = も let _ = も単なるパターンマッチ、または単なる変数束縛です。なぜ単なる let 式がエントリポイントになるんでしょうか。

他の言語、特に OCaml と同系統の言語ではエントリポイントがどうなっているのか、ちょっと見てみましょう。

まあ、じゃあ... Haskell で。

main = putStrLn "Hello, World!"

Haskell では main 関数がエントリポイントとして実行されます。わかりやすいですね。

F# ではこうです。 EntryPoint 属性を指定した関数がエントリポイントとなります。

[<EntryPoint>]
let main args =
  printfn "Arguments passed to function : %A" args
  0

どちらの言語でもエントリポイントには専用の条件があります。なぜ OCaml では単なる let がエントリポイントになるのか - もしトップレベルの let () = や let _ = が特別な扱いを受けるのであれば、私もマニュアルやら技術書やらで目にしていると思うのですが、どうもそんな覚えがありません。お前ろくに技術書なんか読まねえだろって？うるせーよ。

とすると...「なぜ単なる let () = や let _ = がエントリポイントになるのか？」も気になりますが、「なぜ他の let による関数定義がエントリポイントにならない」んでしょうね？そんなの当然だろ何言ってんの、と言われそうです。

うーん、なんで当然なのかと言ったら、関数って呼ばれなきゃ評価されないからですよね。じゃあいつ呼ばれるのかと言ったら、そりゃ呼ばれたとき...などと繰り返しているとバカみたいですけど、正格評価とか遅延評価とか私も耳にしたことがあります。 Haskell は遅延評価ってのが有名ですね。

エントリポイントの話が宙ぶらりんのままなんで、関数呼び出しがどっから始まるのかという問題はさておき、関数が呼ばれる可能性のある部分的な状況を考えてみます。ややこしいですけど、要は関数に渡す引数のことです。例えば次のような式がある場合、

f x y z

大抵の言語だと、引数 x y z の式は左から順に評価されます。 Haskell ではわかりません。いや本当に。どっかで必要になったら初めて計算されるのが遅延評価なんで、この式だけではわかりません。関数 f 内で x y z の値が必要になったら評価されます。

さて OCaml ではどうなのかと言うと、プログラミング in OCaml にこんな一文を見つけました。（「8.3 制御構造」、 164 ページ）

現在の実装では、後ろの引数から順に評価が行われるのですが、 OCaml の言語仕様としては引数の評価順序は未定義なので、...

えっ、今なんと？ OCaml の言語仕様としては引数の評価順序は未定義？ な、なんだってー！コワイ！慌ててググってみると、二項演算式と let 式で評価順序が違うらしいじゃないですか。しかもキャミバ様、もとい神々の使者ラクダ天狗（いや逆では？）もこう言ってるじゃないすか！やだー！

??「OCaml の関数引数等評価順序は左からでも右からでもない…未定！すまんな、本当にすまん。
— 星のキャミバ様 (@camloeba) 2014, 10月 13

ここはドキュメントにあたらねば！ -> 「評価順序は規定されていません」っつー文言が散見されます。うーむ、 mjsk 。

と唸りながらドキュメントを眺めていたら、モジュール式にこうありました。

各定義はストラクチャ内に現れた順に評価されます。

OCaml のソースファイルはモジュールとしても扱われるので、えっと、つまり... let 式は「上から順に評価される」ということ？じゃあ冒頭の "Hello, world!" も順に評価されていただけで、 let () = を二行書いたら二行とも評価されるってこと？こ、こうか？

let () = Printf.printf "1\n"
let () = Printf.printf "2\n"

$ ocaml prog.ml
1
2

なんと...評価された。はー、だから OCaml には特別なエントリポイントは必要なかったわけだ。まあ（たいしてコード書いてないけど）これまで特に困った試しもないので、問題ないんでしょうね。

追記：不定の評価順序

評価順序についてコメントを頂きました。

別のところで書いたことがあるのですが、関数引数の評価順をあえて不定にするのにはそれなりの意味があります。ある特定の引数評価順に仕様を定めてしまうと、その評価順に依存した挙動のプログラムを書くことが堂々と可能かつ正当化されてしまいます。引数の評価順に依存したプログラムは複雑すぎるので書いて欲しくない場合、かつ依存しているかどうか静的に判定かつ禁止できない場合、言語設計者は評価順を積極的に不定にすることになります

なるほど、そういう理由があるんですね。で、ググってみたら C でも関数の評価順序は未規定じゃないですか。手元の本にも「引数の順序は指定されない」て書いてありました (演算子の式の評価順序も同じ) 。うわー、ずっと C 書いてたくせに今更知ったよ...

まあ実は OCaml での評価順序を気にし始めたのも、 MinCaml のソースをつい数日前に見たからなんですけどね。これまで OCaml の評価順序について考えたこともなかったよ (・ω<)

| exp EQUAL exp
    { Eq($1, $3) }
| exp LESS_GREATER exp
    { Not(Eq($1, $3)) }
| exp LESS exp
    /* ここから比較演算子を <= の式に変換。 $1 と $3 の式の位置を逆にしてる */
    { Not(LE($3, $1)) }
| exp GREATER exp
    { Not(LE($1, $3)) }
| exp LESS_EQUAL exp
    { LE($1, $3) }
| exp GREATER_EQUAL exp
    { LE($3, $1) }

よいこのみんな、勉強になったね！（お前だよ

ゼロから始める OCaml

SUZUKI Tetsuya — Thu, 23 Jan 2020 15:24:29 +0000

※この記事は 2014年03月08日に Qiita に投稿したものです。

※追記：オンラインで OCaml 含む様々なプログラミング言語を試せる Wandbox というサービスがあります。強力な基礎ライブラリの Jane Street Core も使えるので、そちらを使うとこの記事はほぼ無意味です。

OCaml に興味津々のみなさんこんにちは、 OCaml ビギナーです。さて、 OCaml とは（ry

ググればわかるような説明はさておき、そこのあなた、 "Ocaml" とキーを叩いてググる暇があるなら（あっ、 "OCaml" でした！）、いますぐターミナルを開いて brew install ocaml しましょう。やれってば。案ずるより産むが易しと言うではありませんか（ Windows でしたか？残念ながら Windows での OCaml は茨の道のようです。なんとか Unix 環境を用意してください）。おや、「 OCaml は仕事で使えるの？」「関数型言語って難しいんじゃない？」という心の声が聞こえましたが、アーアーキコエナーイ。はいはい、ググるだけ無駄です。どこを探しても、今のあなたの役に立つ情報なんかありませんよ？（おっと、誰か来たようだ）

...

はい、 brew install ocaml しましたか？してない？しないの？なんで？ああ、インストール済みでしたか、早く言ってくださいよ（ちなみに OCaml の最新バージョンは、これを書いている時点で 4.01.00 です）。じゃあ、次にビルドツールの OMake をインストールするために brew install omake して...あっ、 Homebrew に OMake なかった...。もし手間を惜しまないなら OPAM という OCaml 用のパッケージ管理ツールをオススメしますが、セットアップが終わるまでになかなか時間を食います。私のような環境構築をめんどくさがるタイプのビギナーにとっては、これが意外と生きる気力をスポイルするんですよね。技術者たる者、そんなこっちゃいかんと日々思っているのですが。まあ準備運動で力尽きないためにも、最初はインタプリタと標準ライブラリだけで学んでもいいでしょう（コンパイラもあります。後述）。

では、 5 分もあればできる恒例の Hello, world にトライしたいと思います。え？手垢のついたつまんねーサンプルはやめろ？いやいや、ビギナーってのは Hello, world と出力するまでの手順すらわからないからビギナーなんです。どんな言語でも、まずはそこから調べないとね。というわけで、 main.ml という名前でファイルを作って、次のコードをコピペしてください。

let () = Printf.printf "Hello, world!\n"

あれ？ Qiita のシンタックスハイライトに OCaml がないよ？（このハイライトは Haskell らしい）まあいいや、このファイルを ocaml の引数に渡して実行してみましょう。

$ ocaml main.ml
Hello, world!

出力されました！やったね！

...これでおしまいにしちゃうと不親切ですかね。ぱっと見て、次の疑問が頭に浮かんだかと思います。

let () = とは何ぞや？
OCaml はインタプリタなの？

let () = とは何か？あー、うん、気にしなくていいです。この右辺にコードを書いておくと、プログラムの起動時に実行されるとだけ覚えておけばいいです。

ocaml コマンドは~~インタプリタですが~~（インタプリタとは言わないとツッコミ頂きました）トップレベル対話環境で、引数にファイルを指定すると面倒なビルド手続きなく実行してくれます。ただ OCaml にはネイティブコードコンパイラ ocamlopt も用意されているので、実際の開発ではこちらを使います。実行速度が違いますからね。その他にバイトコードコンパイラ ocamlc も含まれているのですが、まあ触ってみる程度なら ocaml を、通常の開発では ocamlopt を使えばいいんだと思います。続きは Web で！

さあ、これで OCaml プログラムを動かす方法を一つ覚えました。明日からは好き放題 OCaml を書けますね。うん？ main.ml が膨らんだときにファイルを分割するにはどうすればいいかって？そうですねえ、そこまで困ってから考えればいいと思いますよ。

DEV Community: SUZUKI Tetsuya

OCaml の記号あれこれ

レアリティ：N

(* ... *) (** ... *)

[ ... ]

,

;

&&

||

::

'

|

->

()

^

+. -. *. /.

_

レアリティ：R

[| ... |]

:= <-

= <> == !=

~

?

レアリティ：SR

`

@@

Some @@ x + y;;

|>

let test x y = x + y;;

test 1 @@ 2 + 3;;

2 + 3 |> test 1;;

レアリティ：SSR

;;

@

OCaml の警告オプション（の一部）

【すべてのエラーを】警告 A【消し去りたい】

【ワイルドカード】警告 4 または E【禁止令】

【ラベル嫌いを】警告 6 または L【誅したい】

【俺の名前を】警告 9 または R【言ってみろ！】

【アウトオブ範囲だけど】警告 40【型指定さえあれば問題ないよねっ】

【そんな定義で大丈夫か？】警告 42【大丈夫だ、問題ない】

【お兄ちゃんどいて！】警告 44, 45【そいつ使えない！】

OPAM パッケージ化のススメ

OPAM パッケージ化のメリット

サンプルプログラム

OPAM パッケージを作る

注意点

型安全の夢を一行で打ち砕く黒魔術入門

"type t" とは何か

私的即席プラクティスパターン （※古い内容です）

方針

基本的な型

&str と String

&'static str

Vec<T>

HashMap<K, V>

HashSet<K, V>

Option<T>

Result<T, E>

Box<T>

よく使うマクロ

print!, println!

format!

write!, writeln!

panic!

unimplemented!

unreachable!

try!

vec!

assert!, assert_eq!

debug_assert!, debug_assert_eq!

コーディングスタイル

一度に 5 行以上書かない

コンパイル時のエラーメッセージはよく読む

可変なコレクションには mut を指定する

エラーハンドリングは Result 型で

整数や文字列に特別な意味を持たせない

bool に特別な意味を持たせない（二択でも列挙体を定義する）

unwrap() の落とし穴

レコードのパターンマッチではフィールド値の変数名を省略する

`(* ... *)` `(** ... *)`

`[ ... ]`

`,`

`;`

`&&`

`||`

`::`

`'`

`|`

`->`

`()`

`^`

`+.` `-.` `*.` `/.`

`_`

`[| ... |]`

`:=` `<-`

`=` `<>` `==` `!=`

`~`

`?`

`@@`

`|>`

`;;`

`@`

私的即席プラクティスパターン（※古い内容です）

`'a` とか `t` とかの 1 文字変数の意味

`;;` の意味