キャストの問題が出てきてから色々と考えているのですが、ABの演算部分がかなり簡略化された構造になっとることを再確認させられました。こいつはおいらが1人でABを開発することから、コードの軽量化とその内容のわかりやすさを重視した上でのことであり、言語仕様としては劣る部分でもあります。そこらへんの甘さが、キャストの甘さに繋がっているんですね。

コンパイラの内部構造の話になってしまいますが、ABコンパイラを製作する上で、与えられたBasicの式コードをもとにアセンブラの演算コードを抽出するルーチンがあります。このルーチン、字句解析はもちろんのこと、すべての演算子とすべての型を熟知したものでなければなりません。構造自体はスタックを活用したシンプルなものではあるのですが、扱う演算及び型の種類は日々、多くなっています。この演算と型、掛け算方式で肥大化していくのです。

いわれてもれば、一つの演算をアセンブラコードに変換するためには、右辺、左辺がどのような型なのか、双方の型が違う場合は、どちらの型を優先して演算を行うべきか。足し算だけを見ても、実数演算と整数演算で使用する機械語コードは違うんですね。実数演算ではDouble型とSingle型があるので、2通りに対応するものを作る必要がありますし、整数演算では符号有り無しの考慮、Integer、Word、Char、Byteなど、ビット数が少ないものも考慮しなければなりません。

まだ基本型ならばいいのですが、ポインタ型になるとまたちょっとややこしくなります。ややこしくなる原因はオブジェクトポインタを扱ったときです。AB内部で型を識別するための型コードだけでは、オブジェクトポインタの種類を見分けることはできないからです（オブジェクトポインタはクラスの数だけ存在することになりますから…）。となると、「オブジェクトポインタ」という一つの型コードと、別途クラスコードを管理する必要がでてくるというわけです。

この演算抽出のルーチン、コンパイラ内部のあちらこちらから呼び出されるので、オブジェクトポインタを考慮したものに書き換えるというと大きな作業になってしまうんですね。

こういう問題を抱えつつですが、近日中にキャストの問題をクリアしてより繊細な演算ができるような仕様に拡張していきたいと思います。ウーン、「次回のバージョンアップで…」というのはちと難しいかもしれません。少なくとも、Ver4.1あたりで対応させたいところです(><)