ksakam
commented
4 years ago ただし、ポインタが2つ増えそうであり(cf p102)、ダミーポインタを2つ増やすことでメモリ量へのインパクトを試行してみる(★)。
(p102) 打合せでは、ファイルポインタを#1{}ノードに設定しましたが、$file$ノードに設定すべきです。
(理由)
ファイルポインタはoperator$file$固有の情報であり、opertorとは独立した一般のノードである#1{}ノードに保持させるのは不自然である。
日時: 7/16(木)9:00-11:00 (於:M-cube313) 参加: 天野氏、坂本(記) 資料: (打合結果反映済) cq-code-review-20200716-after.pptx (p95-)
議事内容:(★:宿題 or 検討事項)
・従来のoperatorは基本的にはtq型であるが、lisp型にすべきものがないか確認(★)。 ・$File$は、constructorとはせずにtq型operatorとする(p97<案2>)。 (理由) constructorとは、通常のノードに対して初期化処理を付加したものといえる。 ところが、もともとtq型operetorの位置づけとして「ノードに対する処理」という役割があり、これで対応するのがよさそう(constructorといった新たな概念の導入は不要)。 constructorの導入は、必要となる場面が出てきた場合に検討する。 ただし、ポインタが2つ増えそうであり(cf p102)、ダミーポインタを2つ増やすことでメモリ量へのインパクトを試行してみる(★)。
・phase2でのprint結果は、validなT式である必要がある。 ・オンデマンド評価は必要そうであり、検討要(★)。ただし、実現できそうな見通しはある。 ・parsing -> phase1まではおおむね検討終了、次はオンデマンド評価も含めたphase2の検討(★)。 ・{}導入の理由は、木構造の構造を変えることなくノード毎にbind元ファイルを指定するため(cf p45)。 ・tq型{}のネストは、BNF上は許容されるが、有意かどうかは要検討 ・同一ヘッド内での複数{}の出現は、BNF上禁止 => 構文エラー or 動作不定の扱い。 (例)
{$``$(?)}{$UU$}A(B,C)ただし、将来的にoperatorの結合演算として別途検討要(★) ・構文木の生成は、1パスとする。(p101,103)