Re: Weird byte-compiler tests
Hrvoje Niksic writes:
Jan Vroonhof <vroonhof(a)math.ethz.ch> writes:
> > Does anyone remember what these tests were supposed to do,
>
> To illustrate a few problems with too aggressive optimizing by the
> byte-compiler.
Oh. Yes. Now I remember.
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? (+ n 0.0)
would be considered an obvious attempt to convert n to a float.
I think we have to assume there is some sane purpose to the code and
cater to that.
Is it acceptable that it hoses all other optimizations for
that special case?
Yes.
I've always considered the marker arithmetics a relic from
ancient
times when someone thought it oh-so-cool to be able to increment a
marker or compare it to a number or another marker without bothering
to call `marker-position'. The marker arithmetics is important for
backward compatibility, but in this case we can just as well document
that the result types should not be relied on; they are numerically
correct, but their type cannot be known in advance and can depend on
whether the code is interpreted or compiled.
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.