Re: Weird byte-compiler tests
Kyle Jones <kyle_jones(a)wonderworks.com> writes:
> One thing is, we haven't really agreed the marker behaviour
were
> problems. Should (+ <marker> 0) really be guaranteed to convert
> a marker to integer?
Is there any other reason to add the constant 0 to something unless
you want the integer coercion side effect?
Yes; this kind of code can be obtained from macro expansion. Macros
are also the reason why it can be important that that optimization be
done.
(+ n 0.0) would be considered an obvious attempt to convert n to a
float.
I don't see any intrinsic meaning in (+ n 0.0), and I wouldn't
begrudge our compiler for optimizing it away. If you need to convert
N to float, you can use the more obvious (float n).
Saying that the type of the return value can't be relied upon to
be
a constant is opening a big can of worms. You have to know whether
the result of arithmetic will return a marker or not. Otherwise you
have to do the integer conversion yourself or risk that your
arithmetic results might change if the return value is a marker and
its underlying buffer is modified. The arithmetic functions should
always return constants.
That's bad news, because then all number-related optimizations in
byte-optimizer go down the drain.