「Catyの新スキーマ言語と型システムの必要性」で述べたように、CatyのJSON-centricスキーマ言語構文は変更する予定です。新しい構文の仕様は、大雑把にではありますが、「スキーマ構文の変更案（ラフ）」に記してあります。
新構文の基本的なアイディアは、配列型とオブジェクト型の構成に予約語（キーワード）を使わず、インスタンスと同じ構文を採用することです。また、'<'と'>'で囲まれた型パラメータを導入して、総称（多相）型をまともにサポートします。型パラメータだけではなくて、名前付き値パラメータを渡すこともできます。いくつかの例を示しましょう。
/* 1 */ type shortString = string(maxLength=10);
/* 2 */ type score(max=integer) = integer(minimum=0, maximum=%max);
/* 3 */ type list<_T> = [_T*];
/* 4 */ type pair<_X, _Y> = [_X, _Y];
/* 5 */ type intPair = pair<integer, integer>;
/* 6 */ type nTuple<_T>(size=integer) =
[_T*](maxItems=%size, minItems=%size);
それぞれを以下に解説します。
- 型パラメータも値パラメータも持たない型です。右辺の (maxLength=10) はスキーマ属性の指定で、これによりstring型を制限します。
- 値パラメータを持つ型です。score(max=100) という型は、integer(minimum=0, maximum=100) に展開されます。値パラメータの参照に %max を使ってますが、これは一案で、他の構文になるかもしれません。
- _T という型パラメータを伴ったリスト型の定義です。型パラメータ（型変数）名はアンダスコアから始まる約束です。
- 長さ2の配列を使ったペア型の定義ですね。
- 整数値のペア型です。もちろん、type intPair = [integer, integer]; という直接的な定義でもかまいません。
- 型パラメータ _T と値パラメータ size を持つ例です。nTuple<string>(size=3) と具体化すると、[string*](maxItems=3, minItems=3) と展開されるので、長さがちょうど3である文字列配列になります。
今までのCatyスキーマ構文にも型パラメータはあったのですが、list, tuple などを予約語として、それらにだけ型パラメータを許し、ユーザー定義の型には型パラメータは（値パラメータも）許してませんでした。型パラメータと値パラメータを自由に使用できるようなれば、型定義の自由度は格段に向上しますが、そこまでの要求がすぐさまあるかどうかは疑問です。
それで僕は、本格的な総称の実装を先延ばし（一時棚上げ）にするつもりだったのですが、Kuwataさんは年末年始を費やしてでも実装すると息巻いています。総称と静的型解析は深い関係にあって、総称機構がちゃんとしてないと静的型解析もちゃんとはできません。静的型解析が不十分だと実行の安全性の保証も不十分になります。しかし、次の2つの理由から、致命的にマズイ状況にはならないと僕は思っています。
- 実行時に動的型チェックは常に働いている。
- パイプラインの中途で動的型チェックに失敗しても、トランザクション処理がなされているのでストレージ整合性は維持できる。
静的型解析が不可能な事態は避けがたいので、安全性の確保には、いずれにしろ上の2つのことに頼らざるをえないのです。
Catyの型システムには、スキーマ属性による3値（または4値）論理述語制限も入るので、100%静的に解析可能であることを要求するのはちと無理があります。結局、動的型チェックとトランザクション処理を完全に外すことはできません。
いずれにしても、総称（多相）を含めたCaty型システムの意味論を提示しておく必要があるのは確かです。そうでないと、「構文は変えたが意味論は変わらない」とか「意味領域に存在するが、構文ではまだサポートしてない」といった言明の根拠が無くなってしまいます。と、そんな事情で、Catyの総称型システムを手短に、しかし正確に述べないとなー、と思ってます（来年ですけど）。
「これは便利だ」とか言って機能を追加するのはたいていはリスキーです。型システムに関して僕が気にしているのは、ユーザーによる基本型の追加をある程度認めたいのですが、それが簡単にできること、そしてユーザーが基本型をいくら追加しても全体として整合性や効率性を維持することです。
JSONだけでは基本型が不足しているのは、次のような型がJSONにないことから明らかでしょう。
- binary -- バイナリ型
- dateTime -- 日付と時刻
- money (currency) -- 金額型
- mailAddress -- メールアドレス型
これらを組み込みでサポートしても、利用場面ごとに足りない基本型は出てくるので、プラガブルが望ましいでしょう。ブラガブルな型システムであり、総称と多値論理の述語制限が入るとなると、それほど簡単てわけでもなさそうです。しかし、「わかりやすくて簡単」にしないといけないのですよね、Catyだから。
