* jckのページ#1
-(by [[K]], 2019.05.13)
** (2) 構文をどうするか?
-''[1]'' jckの構文は、2018年のときは
i = j + 3 ;
-みたいなものでした。しかし今、これでいいのかどうかを悩んでいます。
-アセンブラにはメモリアドレッシングがあって、 a[i] = b[i] + c[i]; みたいな記述をjckでも許したいのですが、しかしこれはパースが結構大変です。2018年の時は、すべてのトークンはスペース区切りでとても単純でした。しかし、メモリアドレッシングを考えると、 a[i + 1] みたいなのだって十分にあり得るので、これをパースするのはそれなりには大変です。
-しかしjckは基本的に言語が内部的に使うものであって、そんな人間的に便利かどうかよりは、「機械が解釈しやすいか」とか「機械が生成しやすいか」のほうが重要です。だからこんなにC言語っぽいことにこだわるメリットはあまりありません。
-''[2]'' パースしやすい構文と言えば・・・おお、LispのS式があります。
( + ( mem a i ) ( mem b i ) ( mem c i ) )
-この記法の偉いところは、とにかくカッコの深さだけ追いかければ、これが ( + a b c ) 型であることがすぐにわかることです。演算子の優先順位とか結合方向とか全然関係ないです。
-ようするに、本来は1語しか書けないところを複数の語で書きたいときは ( ) を使うというだけのルールです。これで複数の語を1つにまとめることができるので、パースが統一的でシンプルにできるわけです。
-C言語でもキャストがちょくちょく出てきますが、おそらくjckでも宣言時とは違う型を当てはめて演算したいことは同じくらいよくあるだろうと思っています。そういうキャストがついたりつかなかったりで、またややこしくなるとパースはもっと大変になるわけです。それを踏まえるとS式を採用するのはなかなか筋がよさそうな気はします。
-''[3]'' いや待て、なんか話が変な方向に進んでいる気がしてきた。まず普通のアセンブラを考えよう。普通のアセンブラはS式を使わなければいけないほどに複雑だろうか?No。・・・じゃあどうしてjckのアセンブラは複雑なんだ?キャストってなんだ?
-結局のところ、C言語を真似すれば各CPU用のアセンブラの色が抜けていいかと思ってそうしたけど、C言語の複雑さもいっしょに導入してしまった気がする。まずもっとシンプルにしなければ。
// 代入最適化問題
// オブジェクト指向との関連性