Addendum to previous... The approach of just using a (signed bignum significand, exponent, type code) only occurred to me as I was writing down the possible objections. I find this funny for a couple of reasons.
First, it's the *kind* of approach that someone coming from C/C++ (like myself) is likely to reject. The approach is convenient only if you are implementing your compiler in a language that supports GC. Second, it reveals that the whole exercise was sort of pointless, because (a) constant folding arithmetic in a compiler isn't performance critical, and (b) re-emitting the value in an arbitrarily selected output language is actually *easier* if you *don't* convert the value to a native type in the compiler. In fact, if efficient re-emitting is what you want, you're likely better off storing the significand of the value in decimal-encoded form. Isn't it funny how focusing on a design pattern that worked well for you in the past can so easily blind you to solutions that might work better now? The unifying representation isn't really as convenient as it initially appears, because when you actually go to do arithmetic on those values you have to be careful to respect precision limits. But at least those issues are well-defined and rare.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
