CatyQL-N3 クエリ言語の新しい構文（かな？） - (保存用) 檜山正幸のキマイラ飼育記メモ編

N3はNotation3、RDFの構文でN3ってあったような、それの真似。

CatyのJSONストレージとクエリ言語 - 檜山正幸のキマイラ飼育記の目次に沿って定義する。最後のほうの結論(?)は結局、N3なんて要らねんじゃね。

二項関係による条件
1. 等号
2. 数値の大小比較
3. 文字列のマッチング
4. 所属（型の判定）
論理結合子
配列の条件
オブジェクトの条件
ANYとUNDEFINED
配列に関する全称命題と存在命題

二項関係による条件

N3では、普通のプログラマに馴染みの記号を使う。

関係演算子	英字綴り名	記号
等しい	EQ	==
大なり	GT	>
大なりイコール	GE	>=
小なり	LT	<
小なりイコール	LE	<=
マッチ	LIKE, MATCH	＝~

無名変数（アンダスコア）も省略して、条件は次の形に書く。

'(' 関係演算子記号 JSON定数リテラル ')'

例：

(>= 0)
(== "M")
(== {"x": 1, "y": -3.5})
(=~ /^a.*x/i)
(=~ 'a%')

LIKEとMATCHの区別は、パターン側の構文で決定する。

所属（型の判定は型名）そのものを用いる。

例：

integer -- 整数である
boolean -- 真偽値である
any -- なんでもいい
undefined -- 未定義値である。

論理結合子

&と||を用いる。&&ではなくて&が1個なところが問題になるかもしれない。「スキーマ言語とあわせたい」というのが意図。スキーマ言語側を&&に変える手もある。否定はとりあえず!とする。

記号の候補案	AND	OR	NOT	問題点
C風	&&	\|\|	!	スキーマ言語と違う
折衷案	&	\|\|	!	アンバランス
別な案	&	\|,	!	変な記号
さらに別な案	&	/	!	/は正規表現に使いたい
綴りを使う	and	or	not	タイピングが面倒
綴り別案	&	or	not	中途半端

!(= X) は (!= X) と書いてよい。

配列の条件

配列リテラルと同じ形。オプショナルの'?'、繰り返しの'*'を使ってよい。ただし、繰り返しは最後だけ。オプショナルも出現制限がある。

例：

[integer, integer & (>= 0), (=~ /[a-z]+/)?, (=~ /[a-z]+/)*]

オブジェクトの条件

オブジェクトリテラルと同じ形。オプショナルの'?'、その他のプロパティに'*'を使ってよい。スキーマ言語と同じ。

宣言と名前付きクエリ

query宣言で名前を付けて、他の場所で使ってよい。



query tokyo = (=~ /東京|Tokyo/i);
query tokyoGirl = {

  "addr1" : tokyo,

  "gender":(= "F"),

  "age":(=< 24)

};

対応するスキーマ。



type tokyo = string(pattern ="/東京|Tokyo/i");
type tokyoGirl = {

  "addr1" : tokyo,

  "gender":"F",

  "age": number(maximum= 24),

  * : any?

};

所感

ここまで似てると、別言語と考えるのがバカバカしくなる。@[query]とかのアノテーションで十分ではないか。

@[open]アノテーションは、配列またはオブジェクトの直前に付き、その型がopenになることを明示する。
@[query]アノテーションは、宣言（定義）の直前に付き、すべての配列とオブジェクトをopenに解釈する。


type tokyoGirl_1 = @[open] {

  "addr1" : tokyo,

  "gender":"F",

  "age": number(maximum= 24)

};
@[query]

type tokyoGirl_2 = {

  "addr1" : tokyo,

  "gender":"F",

  "age": number(maximum= 24)

};

あと問題になるのは、ORとNOTの取り扱いだけ。