Type inference in Eiffel?
- Tags:
- type inference
- convert
I'm not really happy with the signature of infix "+" in class NUMERIC. It seems to me that it tells a lie with its like Currents. I understand that the story is that this should be interpreted with respect to the converted object, and not to the text that appears in the program, but it is this that makes me unhappy.
It would be nice to talk about type inference instead. For instance, in the code below, rather than say that the type of the literal 7 is INTEGER_32 (and therefore that the type of the second operand to the addition should also be INTEGER_32, and an INTEGER_32 result should be produced, and then having to talk about the temporary converted object to spin the story), it would be nicer to say that the compiler is inferring that the type of the literal 7 has to be REAL_64. This seems reasonable. :-)
But what about the code below? Can one really claim type inference to REAL_64 when the programmer has explicitly requested INTEGER_8?
I am unhappy again. :-(
Would NUMERIC do it?
If it was NUMERIC instead of like Current, would you be more happy? That is to say:
For backward compatibility, this would require that some descendants of NUMERIC would need to add a convert clause from NUMERIC.
NUMERIC better than like Current
That would certainly be better, but I still don't like it when the programmer specifies INTEGER_8 explicitly, and the compiler treats it as REAL_64 - I would want to see a compile error there.
Backward compatiblity
The only reason why we don't want a compilation error here is for backward compatibility since in the old days INTEGER + DOUBLE (INTEGER_32 + REAL_64 now) was accepted.
Oops
I don know why I said that - with a result-type of NUMERIC then we again have a clean story of type inference. I like it.