{}部の考え方

[kouamano]

20201106 時点の策定

• [原則] T式は定義式でありその評価の結果による木構造（構造体）の変更はない。
• [変更・生成] {}部はジェネレータであり、{}部以降のT式の木構造（構造体）を変更・生成する。ジェネレータ表現もまた、T式である。
  • ジェネレータは生成後のT式に"責任をもたない"のでユーザーが注意して使用すること。
  • ジェネレータの（構造体に対する）作用（構造体変更・生成、print）は、オペレータごとに個別である。
• [現仕様と将来仕様] 現仕様ではジェネレータ部が必ずしも{}により明確化されていない。将来仕様では上記を例外なしに明確化する。

[kouamano]

@ksakam 上記でまちがいないか、確認願います。

[kouamano]

@ksakam 構造体設計というか構造体の操作できになるところが出てきましたが、構造体の議論に入ってからにします。

[kouamano]

@ksakam 次回、新しい言語設計でいままでの問題がクリアできるかを、あらためて確認ねがいます。

• 複数ファイルとりあつかい
  • ファイルポインタとそのバインドは同一ノードに明示するべき？
    例:
  • ($#5{$bind$($#1[2],$#2[3])}[10],#1$file$(A.csv),#2$file$(B.csv)) : ファイルポインタ"$#1"、"$#2"よりそれぞれ、要素を2、３ずつ取得してデータバインド。この際、{$bind$($#1[2],$#2[3])}[10]という同一ノード表現は必須、つまり　{$bind$($#1[2],$#2[3])} と [10] をばらしても無効とすべきか？
  • ファイルオープンは{}内か？
    例:
  • 上記 #1$file$(A.csv),#2$file$(B.csv) は、実は #1{$file$(A.csv)},#2{$file$(B.csv)} が正しい？
• 項／木参照
  • ジェネレータ対象外とするのが簡単そうであるが。。。
• 他？

[ksakam]

@ksakam 次回、新しい言語設計でいままでの問題がクリアできるかを、あらためて確認ねがいます。

現在これまでの議論を踏まえて仕様を中心に整理中で、次回レビューお願いします。

[原則] T式は定義式でありその評価の結果による木構造（構造体）の変更はない。 　　　　　: [変更・生成] {}部はT式（構造）ジェネレータであり、T式の木構造（構造体）を変更・生成する。ジェネレータ表現もまた、T式である。

「仕様」としては、内部的な木構造の観点というよりも評価の有無に基づくことになりそうです({}は評価あり)。この辺も詳細整理中です。

ジェネレータ外で使用可能ば式（関数）は、1. T式そのもを表すtq型のみである。

lisp型は{}外でも使えます(ただし評価対象外)。 (例) $plus$({$minus$(2,1)},3) => $plus$(1,3) // $plus$は評価対象外

複数ファイルとりあつかい ファイルポインタとそのバインドは同一ノードに明示するべき？ 例: ($#5{$bind$($#1[2],$#2[3])}[10],#1$file$(A.csv),#2$file$(B.csv)) : ファイルポインタ"$#1"、"$#2"よりそれぞれ、要素を2、３ずつ取得してデータバインド。この際、{$bind$($#1[2],$#2[3])}[10]の表現は必須、つまりさらに上流に{$bind$($#1[2],$#2[3])}をおいても無効とすべきか？

1や#2等ラベルのスコープはT式全体なので、どこに現れてもかまいません。bind($#1[2],...)等、bindの引数として$#1が現れた時点で、#1$file$(A.csv)の位置によらずopen処理がオンデマンドで実行されます。

なお、ファイルopenのスコープ(いつcloseされるか)は言語仕様上は未定義で、処理系依存です(レビュー資料p65)。 (例: 該当するすべてのノードに対して$#1から必要なCSV値のバインドが完了した時点で$#1をclose)

ファイルオープンは{}内か？ 例: 上記 #1$file$(A.csv),#2$file$(B.csv) は、実は #1{$file$(A.csv)},#2{$file$(B.csv)} が正しい？

はい。#1$file$(A.csv),#2$file$(B.csv)は、$file$をコンストラクタとみなす場合の記法でボツになりました(p97)。

項／木参照 ジェネレータ対象外とするのが簡単そうであるが。。。

実装はそうなると思いますが、検討上はフルオンデマンドの一環で対象とするつもりです(p108)。

[kouamano]

1や#2等ラベルのスコープはT式全体なので、どこに現れてもかまいません。

$#の方のことです。

[ksakam]

$#の方のことです。

定義側の#iのスコープがT式全体ですので、参照側の$#iの位置もT式内のどこでもよい(どの位置からも参照できる)、という認識なのですが。 何か問題あるようでしたらご教示いただければ幸いです。

[kouamano]

($#5{$bind$($#1[2],$#2[3])}[10],#1{$file$(A.csv)},#2{$file$(B.csv)},[5]) たとえば、上記の最後の"[5]"の部分。

ソースが、 {$bind$($#1[2],$#2[3])} であることは、木構造より判明するが、わかりにくい。

[ksakam]

いまさらですが、まず確認させてください。

ファイルポインタとそのバインドは同一ノードに明示するべき？ 　　　　　　　　　: この際、{$bind$($#1[2],$#2[3])}[10]の表現は必須、つまりさらに上流に{$bind$($#1[2],$#2[3])}をおいても無効とすべきか？

たとえば、上記の最後の"[5]"の部分。

実際に問題にされているのは以下のような表現でしょうか。 つまり、ファイルポインタを引数とする$bind$のノードと、バインド先ノード[5]が別ノードである。

$#5{$bind$($#1[2],$#2[3])}(#1{$file$(A.csv)},#2{$file$(B.csv)},[5])

なんだか誤解してるようで、すみませんがご指摘ください。込み入った内容であれば次回でも構いません。

[ksakam]

すみません、ミスプリ修正しました。

誤: ($#5{$bind$($#1[2],$#2[3])}(#1{$file$(A.csv)},#2{$file$(B.csv)},[5]) 正: $#5{$bind$($#1[2],$#2[3])}(#1{$file$(A.csv)},#2{$file$(B.csv)},[5])　　// 先頭の'('を削除

[kouamano]

つまり、ファイルポインタを引数とする$bind$のノードと、バインド先ノード[5]が別ノードである。

そういうことです。

[ksakam]

そうすると、「例えば{$bind$($#1[2])}は、後続のT式内の対象ノードに、ファイルポインタ$#1内のCSV値をバインドする」という$bind$の定義自体が問題であるということでしょうか。 例えば、以下の式もNGとなりそうです。

({$bind$($#1[2])}A[](B[1],C[2]), #1{$file$(test.csv)})　// {$bind$($#1[2])}の後続のT式はA[](B[1],C[2])、バインド先ノードはB[1]、C[2]

であるとして、ご指摘は「{$bind$(...)}によるバインド先ノードは、{$bind$(...)}に後続する直後の1個のノードのみに限定すべき」という理解でよいでしょうか。

[kouamano]

「{$bind$(...)}によるバインド先ノードは、{$bind$(...)}に後続する直後の1個のノードのみに限定すべき」 正確には二つのことを精査してほしい、となります。 (1)件のノードをまたがるデータバインドは可能であること、その具体的な処理（すでに述べたようにそのように解釈可能と考えています） (2)その上で、この分かりにくい表現を許すか

[ksakam]

正確には二つのことを精査してほしい、となります。

了解しました。今のところ(1)(2)ともyesになりそうですが、いずれにしろ次回議論お願いします。

P.S. 次回は仮で以下にしてましたが、この日程で確定でよいでしょうか。 21(金)18:00～(於:Mcube 116)

[kouamano]

正確には二つのことを精査してほしい、となります。

了解しました。今のところ(1)(2)ともyesになりそうですが、いずれにしろ次回議論お願いします。

P.S. 次回は仮で以下にしてましたが、この日程で確定でよいでしょうか。 21(金)18:00～(於:Mcube 116)

いまのところ、だいじょうぶです。

[ksakam]

$#5{$bind$($#1[2],$#2[3])}(#1{$file$(A.csv)},#2{$file$(B.csv)},[5])

(2)その上で、この分かりにくい表現を許すか

いずれにしろ明日議論をお願いしたいのですが、わかりにくさの根本原因は以下の点でしょうか。

「$bind$のターゲットであるT式(ツリー)内に、ソース#1{$file$(A.csv)}とターゲットノード[5]がごちゃ混ぜに混在している。」

[ksakam]

{}に関して非常に気になる点が生じました。

{}の規定(#94の打合資料p121)

    { l_opn(x1, ..., xn) }  => t        // l_opn / t_opn    : n変数lisp型 / tq型operator (n≧0)
    { t_opn(x1, ..., xn) }  => t_op0    // t, x1, ..., xn   : T式

これによると、{}の評価結果として、 　(a) {lisp型}はT式 　(b) {tq型}はoperator

(問題点) 　T式は記号の世界(構造のみで「意味」には関知しない)、operatorは意味の世界(関数や集合など、モデルの世界) 　　=> 同じ{}の評価結果として、あまりにも次元が違いすぎ 　　=> 合理的な説明必要

[kouamano]

@ksakam 意味は一切扱わないのでは？ operatorといってもT式に対するオペレーターでは？

[ksakam]

@ksakam 意味は一切扱わないのでは？ operatorといってもT式に対するオペレーターでは？

例えば、print処理において$PI$は内積処理を指示しますが、「内積処理」は記号「$PI$」があらわす意味といえないでしょうか。 であれば、記号「$PI$」と意味「内積処理」のmappingを意識せざるを得ません(つまり意味を扱っている)。

で、上記{}の定義内「t_op0」を「内積処理」等の意味を表す記号であるとみなせば、tq型の評価結果も記号の世界に収めることができそうです。ただ、この記号はなにもの?って感じです。

そもそも、「記号」とか「意味」とは何のことを言ってるか、を含めて整理中です。

[kouamano]

数式処理的解釈は、意味処理などではなく、「表現評価系による項書き換え」となります。これは、「式全体（=記号列）を見て、多項式に置き換え（この時点でトークナイザーによる「意味」がすでに発生）、多項式書き換えルールを駆使して（ここにも「意味」が発生）多項式表現が変化しなくなるまで書き換える」ことであり、これに「意味」を持ち出すならば、（）内の説明の通りです。それはそれで構わないと思いますが。 それとも、「t_op0」や「内積処理」という表現そのものを、気にされているのでしょうか？

私はそもそも、「意味」という言葉をできるだけ使わないようにしています。ほとんどの場合、「ルール」とか「解釈」に置き換えられます。

tqの場合は、「意味」はそれがなんなのかを考えるまでもないくらい限定的である（種類としては上記の二つ）、で良いと思います。

[kouamano]

tqの処理の解釈を難しくしているのは「評価」と「実行」があるからでしょう。私個人は、坂本さんの表のようにそれぞれをちゃんと定義すれば良いと考えますが、より一般的な説明がほしいということであれば、「多重パラダイム項書き換え」ではないでしょうか。

[ksakam]

私も、意味処理などといった際の高度な「意味」ではなく、限定的のつもりです。 私の言ってる「意味」とは、論理学でいうところのモデルに近いのではと思います。 論理式中の述語記号・関数記号・個体記号などの記号に対して、集合論でいうところの述語・関数・個体をmapping。 tqでいうと、「$PI$」という記号に対して、内積という関数なのか演算なのか何なのかをmapping。

だいぶまとまりつつあると思うので、まずは整理を仕上げます。

[ksakam]

(1)件のノードをまたがるデータバインドは可能であること、その具体的な処理（すでに述べたようにそのように解釈可能と考えています） (2)その上で、この分かりにくい表現を許すか

いずれもyes。特に(2)はユーザ責任とし、システム側で制限をかけることはしない。(cf https://github.com/kouamano/RECURSIVE-SYSTEM/issues/95 )

[kouamano]

議論は落ち着いたと思うので、close。