search

kouamano / RECURSIVE-SYSTEM

test for recursive operation
3 stars 1 forks source link

tq/cqコードレビュー議事メモ(2020.5.29) #77

Closed ksakam closed 3 years ago

ksakam commented 4 years ago

日時: 5/29(金)8:00-10:00 参加: 天野氏、坂本(記) 資料: (打合結果反映済) https://github.com/kouamano/RECURSIVE-SYSTEM/blob/cq/Document/cq-code-review-20200529-after.pptx

議事:

  1. reference chain 　資料記載のとおり。 ・従来の値指定の＠は%に変更する。 => これについては実装の検討に着手する。 ・出力の順序は変更なし 　　自ノード%、参照先ノード%、(バインド値 or 参照先の子ノード)、(バインド値 or 子ノード) ・復元できないという課題は、復元の必要性も不明であり当面pending。 ・参照列head内の[]は、head末尾の[]のみバインド指定とみなす。末尾に[]が連続した場合は多次元とみなす。 =>現実装を要確認 ・reference指定「$#n」は、何らかの出力を指定しているという意味でオペレータとみなす。ただし、記述形式は要検討($PI$など通常のオペレータと相違している) ・read/eval/printループの検討を復活させる。 => 履歴管理とセットで検討(履歴管理は現状でも未サポートのため、なしでもspec downにはならない) ・head末尾の[]のみバインド指定とみなす。 ・末尾に[]が連続した場合は多次元とみなす。 =>現実装を要確認 ・tq言語仕様の特徴を整理の上、学術的意義を明確化する必要 (例) @%はデリミタとしない。 (理由) parsingが簡便-> グラフツリーの表現を重視しparsingには労力かけない。 ・内積処理のn番目の値の出力処理において、資料記載の通り出力順序をrefer先のあとバインド値と変更する。ただし、NS3との整合性に要注意。 ・%への変更については、実装準備に着手

  2. bindオペレータの導入 　資料記載の通り。 ・「$#1:$##2[2]」において、「$#1」のバインド対象は「$##2」自身であり、参照先ではない。 ただし、現実装を要確認。

  3. ストリームの有効`範囲 ・<案2>に決定。ただし、実装はpending

  4. 複数ファイルとのバインド ・仕様記載の案ではなく以下の2案が有力。 　- 案1: $exec$ + $eval$の導入 　　-> 以下の文字列を生成($exec$)+評価($eval$) 　　　　($#1:[1],$#2:[1],$#1:[1],$#2:[1],...) 　- 案2: flatten関数の導入 　　-> バインド値に対する演算

　=>いずれにしろpending

  1. 内積出力形式の定義 　資料記載の通り
ksakam commented 4 years ago

　　-> 以下の文字列を生成($exec$)+評価($eval$) 　　　　($#1:[1],$#2:[1],$#1:[1],$#2:[1],...)

さきほど以下で対応可能かもしれないと申し上げましたが、NGです。はやとちりですみません。 　　　　　$PI$([]($#1:[1],$#2:[1])) (理由) 　　やりたいのは、1個のノードに$#1、$#2の値を交互にバインド。上式では、2個のノードにバインド。

(別案) 「:」の拡張(連結可能) 　　交互に読込むファイルポインタを読込個数(デフォルト1個)とともに連結。 　　　　$PI$($#1:$#2[2]:A[6]) 　　　　=> ($#1から1個、$#2から2個)の反復により、Aに6個の値をバインド。

　　　　$PI$($#1:$#2[2]:A[](B[2],$#3:$#1[2]:$#3:C[5])) 　　　　=> ($#1から1個、$#2から2個)の反復により、T式「A[]～」に値をバインド。 　　　　ただし、「C[5]」には、($#3から1個、$#1から2個、$#3から1個)を反復。 　　　　(同じファイルポインタが複数個所に現れてもよい)

(補足) 「:」や「[]」は非デリミタのまま。

kouamano commented 4 years ago

@ksakam バインド指示はオペレータとしての解釈で行う、ということだったと思いますが、そうすると、提示の仕様は、<head>::=<ref-label>?<reference>?<operator>?<label>?<bind>? にそぐわなくなるので表示順序の入れ替えが必要ではないですか？

また、オペレータ表現に厳密に従うなら、少々表現がくどくなりますが、$#1:$とやはり最後に"$"が必要かと。

kouamano commented 4 years ago

そうすると、 : => オペレータ結合 $#1[]$ => バインドオペレータ $PI$($#1:$#2[2]:A[6]) => $PI$($#1[1]$:$#2[2]$A[6]) あるいは $PI$($#1[1]:#2[2]$A[6])

ちなみに、上記例$#1:には[<n>]が必要=>$#1[<n>]:かと。なぜなら、$#1: = $#1[]:では、$#1から際限なくバインドされる解釈になるはず。

kouamano commented 4 years ago

@ksakam そういえば、:が必要になった理由ってなんでしたか？

ksakam commented 4 years ago

本日の打合せ結果をまとめました。

日時: 6/3(水)9:15-9:45 参加: 天野氏、坂本(記) 議事内容:

(原案) $PI$($#1:$#2[2]:A[6]) に対して以下(a)(b)の対案あり。 (a) $PI$($#1[1]$:$#2[2]$A[6]) 　　「$#i[n]$」=> バインド指定オペレータ(ファイル#iからn個読込を反復) 　　「:」　　=> オペレータの結合オペレータ(一般の関数結合 f○g 相当) (b)$PI$($#1[1]:#2[2]$A[6]) 　　「$#1[1]:#2[2]$」=> バインド指定オペレータ 　　　　　　　　　　　　(ファイル#1、#2からそれぞれ1個、2個読込を反復) 　　「:」　　=> ファイルの列結合オペレータ

(結論) ・当面(b)を実装する。 　(a)については一般の関数結合の観点で継続検討。特に「$#1[1]$」と「$#2[2]$」を一般の関数結合オペレータとしての「:」で結合した際に、「$#1[1]$:$#2[2]$」の意味が期待通りに説明できるか。 ・(a)(b)によれば、バインド指定としての「:」は不要(注1) ・$#i[n]において、[n]省略時のデフォルトは[](ファイル終端に到達するまで無限個)とする。 ・%もオペレータとみなす。 　(例) $%$A(T1,T2) => ノードAにT1,T2をバインド 　「$%$」の記述は要見直し。(例)$VALUE$A(T1,T2) ・(b)に基づく列結合をアピールする複数ファイルの紙芝居検討(坂本)

(注1) バインド指定の「:」が必要だった理由は以下の通り。 　CSVファイル「$#1」をT式「A[2](B[1],C[2])」にバインドしたいとき(1)のように書くが「:」がないと(2)のようになって「$#1A[2]」がヘッドとみなされてしまう。 　(1)$#1:A[2](B[1],C[2]) 　(2)$#1A[2](B[1],C[2])

(次回レビュー) ・(b)の詳細化 ・$%$の詳細化 ・referenceのオペレータ化 ・辞書関連のレクチャ(担当:天野様)

ksakam commented 4 years ago

$PI$($#1[1]:#2[2]$A[6])

値指定のバインドである$%$の見直しと併せて、以下の記述でどうでしょうか。 オペレータに対してパラメータを指定できる機構を導入します。

(a) $PI$($bind:$#1[1]:$#2[2]$A[6]) 　=> CSV値のバインド ($#1[1]、$#2[2]はbindのパラメータ、:はパラメータ区切) (b) $PI$($bind$A(T1,T2)) 　=> 値指定のバインド (パラメータなし)

(補足) 「:」は、bindに限らず一般のオペレータでもパラメータ区切として使用可 　　　<一般形> $op:p1:p2:...:pn$　　(opはオペレータ、piはパラメータ、:はパラメータ区切) 　=>「:」は、関数結合オペレータとしては使えなくなる。

ksakam commented 4 years ago

(a) $PI$($bind:$#1[1]:$#2[2]$A[6]) 　=> CSV値のバインド ($#1[1]、$#2[2]はbindのパラメータ、:はパラメータ区切) (b) $PI$($bind$A(T1,T2)) 　=> 値指定のバインド (パラメータなし)

(a)(b)の統一感がないので、(b)は以下(b')も考えられます。referenceのオペレータ化と併せていくつか案を整理してみます。

(b') $PI$($bind:"(T1,T2)"$A) 　　=> 値指定のバインド(指定値はbindの文字列パラメータ)

(a)(b')の違いは、bindのパラメータがファイルポインタであるかT式文字列であるかの違い。

kouamano commented 4 years ago

@ksakam スライドをupdateしました。bindオペレータと":"はまだ反映してません。

2020-06-10 坂本さんの案と少し違いますが、updateしました。

kouamano commented 4 years ago

実装について： 現在、スキャンが「in-file読み込み」、「out-file読み込み」、「内積適応」の3パス。 レファレンス解析は、「in-file読み込み」時、「out-file読み込み」時の操作として行われ、事実上スキャンを消費しない。 このコストを維持するため、「内積適応」部をバックトラックなし／1パスの「関数適応」に変更可能か？