tq/cqコードレビュー議事メモ(2020.5.1)

[ksakam]

日時: 5/1(金)10:00-12:30 参加: 天野氏、坂本(記) 議事:

1. reference chain 　添付資料記載の通り。要点以下の通り。

(1)構文

• 一般形: X%(t,...,t)(T,...,T)@Y%(t,...,t)(T,...,T)@...@Z%(t,...,t)(T,...,T)
• BNFには、従来の<T-form>に加えて、reference-chainを許容する<ext-T-form>を導入する。
• @はデリミタ、%は通常文字扱いとする。
• 資料に自ノードや参照先ノードの子ノードの記載(上例(T,...,T))が漏れているため、追加する。 => 打合せ後に見直しの結果、子ノード追加に関連して簡潔なBNF記述のため検討要

(2)内部表現 　以下の通り、従来のT式で表現する。

• $ref-chain$(X%(t,...,t)(T,...,T),Y%(t,...,t)(T,...,T),..,Z%(t,...,t)(T,...,T))

2. ストリーム (1)ストリーム種別 　ストリームをどういうフォーマットでreadするかはreadするオペレーションで決定し、フォーマットごとにストリームクラスを提供することはしない。 　=>上位クラス$stream$の下位クラスとして、＄file＄、$string$、$exec$、$socket$を提供する。内容のフォーマットは自由。 　=>ストリームの種別として、$csv_xxx$、$json_xxx$など、特定フォーマットを想定したストリームはなし。 　=> T式をCSV値として読みこむ話もキャンセル。(資料p57)

(2)bindオぺレータ 　bindオペレータ:を導入する。 　　<stream ptr> : <T-form>　　=> 左辺のCSVストリームを右辺のT式にbind

• :の左辺はstreamへのreferenceに限定し、一般のT式は禁止する。 　　=>(理由) 右辺T式の構造変化回避のため(cf資料p45)
• 以下の案も出たが、同様の理由で取下げ

  $file$(“file”)($T$(...))
  $file$(“file”,$T$(...))
  #1$file$(“file”),$#1($T$(...))

  　　=> $file$が、引数であるT式へのbind機能を内包するという発想に基づく。(cf 資料p45 案2)

• :は%同様非デリミタで、ヘッド内の文字位置は解析容易性により決定。

3. 内積出力形式
   • 資料記載の出力結果は設計意図を反映しており、これをベースに明確な規則化を行う。(宿題) 　ベースにあるのは、テンソルの表現。以下で表示されるNS3仕様も考慮すること。 tq.o -h -hF -hC -hS -hD -hE -s -c -CL

(資料) cq-code-review-20200501-after.pptx

[kouamano]

レファレンス構文
やはり、現仕様で良いのではないか？
(例)

echo '($##1,##1$##2(A),##2$##3(B),##3(C))' | ./tq.o in=/dev/stdin -FT -Pin
($##1@##1$##2@##2$##3@##3(C)(B)(A),##1$##2@##2$##3@##3(C)(B)(A),##2$##3@##3(C)(B),##3(C))

(解釈)

"$##3"のレファレンスは"##3(C)"であり、これに対する引数"B"がある。
"$##2"のレファレンスは、レファレンス解決された##2以降の木であり、これに対する引数"A"がある。
"$##1"のレファレンスは、レファレンス解決された##1以降の木である。

(データバインド)

データバインドはリーフノードしか対象にならないので、この問題はないはず。
echo '($##1[1],##1$##2(A[1]),##2$##3(B[1]),##3(C[1]))' | ./tq.o in=/dev/stdin -FT -Pin data=num.csv
($##1[1]@@##1$##2@##2$##3@##3(C[1]@(4))(B[1]@(3))(A[1]@(2))(1),##1$##2@##2$##3@##3(C[1]@(4))(B[1]@(3))(A[1]@(2)),##2$##3@##3(C[1]@(4))(B[1]@(3)),##3(C[1]@(4)))

[ksakam]

レファレンス構文 やはり、現仕様で良いのではないか？

> echo '($##1,##1$##2(A),##2$##3(B),##3(C))' | ./tq.o in=/dev/stdin -FT -Pin
> ($##1@##1$##2@##2$##3@##3(C)(B)(A),##1$##2@##2$##3@##3(C)(B)(A),##2$##3@##3(C)(B),##3(C))

　値指定の@を%に変更するだけで、他は従来通りということですね? 　　・参照先指定の@は非デリミタ 　　・print時の出力順序は、自ノード、参照先ノード、(子ノード or バインド値)

[気になる点]

(例1)
$ echo '($##1(A),##1$##2[1],##2)' | ./tq.o in=/dev/stdin -FT -Pin data=num.csv
　=>($##1@##1$##2[1]@@##2(1)(A),##1$##2[1]@@##2(1),##2)

(例2)
$ echo '($##1,##1$##2[1],##2(A))' | ./tq.o in=/dev/stdin -FT -Pin data=num.csv
　=>($##1@##1$##2[1]@@##2(A)(1),##1$##2[1]@@##2(A)(1),##2(A))

[$##1のref-chain]　　　　　　　　　　　　　　　　(->以降は%導入の新形式)
　　例1: $##1@##1$##2[1]@@##2(1)(A)　　　-> $##1@##1$##2[1]%@##2(1)(A)
　　例2: $##1@##1$##2[1]@@##2(A)(1)　　　-> $##1@##1$##2[1]%@##2(A)(1)
   <構文>
　　$##1@##1$##2[1]@@##2 : 全体で１ノード(%や@が非デリミタのため)
　　(A)、(1) : その子ノード(ただし、1は本来##1$##2[1]のバインド値)

(問題点) 　　例1: 1、Aは、それぞれ、$##2のバインド値、$##1の子ノード 　　例2: 1、Aは、それぞれ、$##2のバインド値、##2の子ノード

　これらの例において、(1)、(A)の順番の違いのみでref-chainは同様の形式であり、ref-chainだけからは以下の特定は不可であるが問題ないか。 　　　・(A)や(1)がバインド値なのか子ノードなのか 　　　・(A)や(1)が入力T式内のどのノード($##1 ,$##2, ##2)の子ノードやバインド値なのか

　=> 特定不可が問題かどうかは@の意味づけに依存?

[kouamano]

以下の、元の式が特定できない問題は、それで良いとするかも含めて検討事項としましょう。

[$##1のref-chain]　　　　　　　　　　　　　　　　(->以降は%導入の新形式)
　　例1: $##1@##1$##2[1]@@##2(1)(A)　　　-> $##1@##1$##2[1]%@##2(1)(A)
　　例2: $##1@##1$##2[1]@@##2(A)(1)　　　-> $##1@##1$##2[1]%@##2(A)(1)
   <構文>
　　$##1@##1$##2[1]@@##2 : 全体で１ノード(%や@が非デリミタのため)
　　(A)、(1) : その子ノード(ただし、1は本来##1$##2[1]のバインド値)

その上で、現時点では、 　値指定の@を%に変更するだけで、他は従来通りということですね? としましょう。 以上、 @ksakam 次回資料に反映してください。

[ksakam]

了解いたしました。 元の式の復元については、@の意味づけとセットで継続検討ということですね。

[kouamano]

そうです。で、一つ、新しい解釈を思いつきました。 「引数グループ」です。

現在、"A(B)(C)"のような形式は、Aが親でBとCがその子とし、同じ木レベルで解釈されますが、 BとCはそれぞれグループ化されており（そのはずなので確認してください。）、A(B,C)から拡張された構造になっています。 当該表現をさらにこの拡張として捉えれば、"A(B)@(C)"はの"@"は、Cのグループ名と解釈できそうです。 Head直後の引数のグループ名はHeadそのものとし、第二グループ以降は好きに名前をつけられるとします。 "A(B)A(C)X(D,E)"の解釈は、A(B,C,D,E)という木であり、Cは第二引数グループでその名前は"A"、D、Eは第三引数グループでその名前は"X"ということになります。

どうでしょうか。

[ksakam]

すみません、じっくりとは少しお時間いただきたいのですが、取り急ぎ以下が気になります。

(Q1)

"A(B)@(C)"はの"@"は、Cのグループ名 "A(B)A(C)X(D,E)"の解釈は、A(B,C,D,E)という木であり、Cは第二引数グループでその名前は"A"、D、Eは第三引数グループでその名前は"X"

@、C、A、Xいずれも名前ということは、@自体には特別な意味は持たせない、ということでしょうか。

(Q2) $##1@##1$##2[1]%@##2(1)(A)　では@が(...)の前ではなくヘッドの中に現れますが、この場合はどういう解釈になるでしょうか。

[kouamano]

(Q1) 一旦、@の使い方の議論を離れ、式解釈の拡張を考えます。これが引数グループです。つまり、@の特別な解釈は行わない、ということは踏襲します。（行ってもよいがユーザー解釈）

(Q2) headの一部として解釈します。（今まで通り）

[ksakam]

@の意味づけとは独立した議論ということですね？ 議論の位置付けは理解しました。

BNF化など検討してみましょうか。

[kouamano]

そうです。 まずは、"()XXX()"のような表現を受け入れるための一般的な解釈を考えます。

BNF化など検討してみましょうか。 そうですね。もう行ってもよいと思います。

[ksakam]

まずは、"()XXX()"のような表現を受け入れるための一般的な解釈を考えます。

そうですね、一般形を精密化してみます。