jck_0001
のバックアップ(No.2)
[
トップ
] [
新規
|
一覧
|
単語検索
|
最終更新
|
ヘルプ
]
バックアップ一覧
差分
を表示
現在との差分
を表示
ソース
を表示
jck_0001
へ行く。
1 (2019-05-13 (月) 13:42:44)
2 (2019-05-13 (月) 14:09:31)
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式を採用するのはなかなか筋がよさそうな気はします。