行き詰まったけど、出口を探してます。
配列が無理矢理な実装だったので、先に進む気になれません。
もっとごちゃごちゃになる事は必須です。
ってことで、他の処理系を見て移植してみようとして規模に圧倒されて参っている今日この頃です。
そこで、本読んで、なにをやっているかをちゃんと把握しようとかしています。
Cフラットと作ろうとしている処理系の違い
1.visitorパターンはパターンマッチに置き換えたい
visitorパターンは理解しずらいのでパターンマッチに置き換える必要があります。
2.javaccはscalaに式を使って解析してパターンマッチで解析する
これにより、Lispと同じようなマクロを実行出来るようにします。
3.垂直分割を水平分割にする
現状は、classの中に各処理が分散しているのですが、各パスで分けます。
4.アセンブラDSLはなくす
抽象化なので無くしてプログラムを短くします。
5.メイン関数を分かりやすくします。
ぱっと見て複雑と感じてしまったので全体を把握しやすく書き換えます。
cフラットとtcc
1.visitorパターン
あり なし
2.javacc
あり なし
3.垂直分割を水平分割にする
あり なし
4.アセンブラDSLはなくす
あり なし
5.メイン関数を分かりやすくします。
あり なし
6.抽象度
高い 低い
tccは抽象度が低すぎて移植するにはシンドイです。
Cフラットでは定義をあとからしても大丈夫なように、定義読み込みのみ先に行うようになってます。
mincamlとかはどうなのかな？分からない、、、。
俺作った奴は型チェックしてないので謎だ。ちゃんとしたコンパイラには必要な処理なのでしょう。
でも今は、チェックをしたいのではない。とにかく動く物を作りたい。
今抱えている問題をあげてみる。
1. 型のサイズの扱いに無理がある。
複数の型に対しての型のサイズを求める方法がいい加減なので何らかの方針が必要です。
2. 暗黙の型変換が無い
これがないと、ポインタ計算とかする所で辛いです。
3. ポインタの型をどう扱うかがいい加減です。
これも方針が必要です。
Cフラットでは、型を表すクラスがサイズを持っています。
ポインタはそれぞれ別なクラスが良いされていました。
ポインタは型のポインタである。っていう扱いで扱えないのかな？と漠然と思います。
うーん。なんか、何が分からないかが分かって来た感じです。
型のサイズをどう扱うかが決まれば何かとスッキリするはず。
ということで、型のサイズを美しく扱う方法を考えて行きたいと思います。
型テーブルに突っ込んでおくか、それぞれの変数に型情報としてサイズも乗っけるかですね。たぶん。
型の名前か、型の実態を参照する形で必要な所まで持ち歩いて、最後はアセンブラになって消えるという感じかな。
今は、LISPっぽくなってて、全部多値で表しているけど、型を持たせた処理系に作り変えるのも手。型を作るとソース長くなるのでとりあえず、型は作らずタグのように型情報をタプルにくっつけて扱うのが短くてすむ。
等と悩んでる今日この頃でした。
Scalaで書かれたコンパイルの処理系も色々あって楽しいです。githubで検索するとちょっとだけ、処理系が見つかります。
でもなんだろうなぁ。俺がやっている事って、高い給料をもらえる仕事を只にしてしまうという事を苦しんでやっている。誰も褒めてくれない。
賞金がある訳でもない。辛いだけ辛いんです。
でもなんか、面白いんだよな。コレは間違いない。
出来上がってしまえば、きっと、万有引力とかみたいに当たり前の事になるんじゃないかと思います。
縺れた糸を解きほぐす。それが面白いんだろうなぁ。
名声が欲しい訳でもなく、ただ、短く、美しく書きたい。
そして、書けるはず。探しても無いのは、隠されているか、無いから。
追い求めて行けば、自分もまた隠すことになるかもしれない。
その方が金銭的に得だから。
でもなぁ、それじゃ面白くないなって思っている自分がいる。
