このブログの更新は Twitterアカウント @m_hiyama で通知されます。
Follow @m_hiyama

メールでのご連絡は hiyama{at}chimaira{dot}org まで。

はじめてのメールはスパムと判定されることがあります。最初は、信頼されているドメインから差し障りのない文面を送っていただけると、スパムと判定されにくいと思います。

参照用 記事

Catyの新スキーマ言語と型システムの必要性

Kuwataさんと打ち合わせて、Catyのスキーマ言語の構文を変更することにしました*1。「プロトタイプ・フェイズでは、仕様変更を躊躇しない」という方針です。とはいえ、ソフトウェアの規模が大きくなるにつれて、仕様変更に伴なうKuwataさんの作業負担も増大しています。どうでもいい変更はしません。

スキーマ言語構文を変えるのは少し先(JSONストレージが落ち着いてから)になるでしょう*2が、この変更には明らかなメリットがあります。キーワード(予約語)が減って、構文が簡略化されます。例えば、列挙型とユニオン型*3は同じ構文になります。

  1. 列挙型 ("red" | "green" | "blue")
  2. ユニオン型 (string | integer)

そして、JSONインスタンス構文(リテラル)とスキーマ構文の区別がなくなります。これは、JSONインスタンスをそのまま(ほんとにソノママ!)型定義とみなせることを意味します。JSONインスタンスを少しずつ変更して型定義を組み立てることができます。このことは、学習を容易にする効果も相当にあるでしょう。

例を挙げます。まずは、次のJSONインスタンス:

{
 "name" : "檜山正幸",
 "gender" : "male"
}

これはそのまま型とみなせるのですが、単一のインスタンスだけを含む型(シングルトン型)です。シングルトン型ではつまらないので、少し変更します。

{
 "name" : string,
 "gender" : "male"
}

具体的な値 "檜山正幸" に代えて型名 string を入れたので、"name"プロパティ(人の名前)は任意の文字列を許すことになります。直感的な意味は「男の人」ですね。

男の人だけではなくて、女の人も含めるには次のように直します。

{
 "name" : string,
 "gender" : ("male" | "female")
}

これで、"name"(人の名前)と "gender"(性別)という2つのプロパティを持った型が定義できました。

人の名前を、2文字以上/20文字以内の文字数に制限したいなら、次のようにスキーマ属性で修飾します。

{
 "name" : string(minLength = 2, maxLength = 20),
 "gender" : ("male" | "female")
}

こうして定義された新しい型に、personという名前(型名)を付けたいなら、次のような型定義文を書きます。

type person = {
 "name" : string(minLength = 2, maxLength = 20),
 "gender" : ("male" | "female")
};

こんな型定義文を書くのは嫌だという人は、HTMLのフォーム構文を使って定義しても構いません*4

<form name="person">
 <p>お名前:<input type="text" 
            name="name" datatype="string(minLength = 2, maxLength = 20)" >
 </p>
 <p>性別:<input type="radio" name="gender" value="male"><input type="radio" name="gender" value="female"></p>
</form>

ラジオボタンが列挙型の表現であることはただちに分かるので、何も書く必要はありません。テキストフィールドはいろいろなデータ型の入力に使われる可能性があるので、datatype属性でデータ型を明示します。ただし、単なるstringならdatatypeを書く必要はありません。

データ型の設計が先行するならスキーマ構文を使って書けばいいし、HTMLフォーム作成が先行するなら、HTMLファイルからスキーマ(型定義)を抽出すればいいわけです。

Catyは、プログラミングとデザインの作業を、できるだけ並行して進められように、時間的にどちらが先行してもよいように配慮しています。プログラムが先行しているなら、型定義文に従ってHTMLフォームを作ることになるでしょうし、HTMLフォームが先にあるなら、そこから抽出した型定義にあわせてプログラムを作ることになるでしょう。HTMLフォーム(入力)、プログラム(処理)、テンプレート(出力)、それとJSONストレージ(保存)のあいだに型の不整合があれば、Catyの型システムがただちに検出して報告します。

Catyにとって、強い(strong-typingでありパワフルな)型システムが必要だった理由は、こういうことを可能にするためです。Catyの目的は、「ものすごく簡単に、安全でしっかり動くWebサイトを作れること」なんですが、そのためには、強烈で精密な型システムと極めて単純なスクリプト言語を備えた言語処理系エンジンを基盤にするしかなかったんです。僕らはこれが、設定した要求に対するミニマムな仕掛けだと思っています。

*1:変わるのは構文だけで、型の意味論は変わりません。意味論は、圏論と領域理論を使って組み立てます。

*2:次のリリースには入りません。

*3:Catyのユニオン型は排他的ユニオンしか認めてません。これにより意味論が劇的に簡単になります。

*4:HTMLフォームにより定義できるのはJSONオブジェクト型に限りますが、実用上はそれでも十分でしょう。