Re: Numerics

On 25/03/2005, at 8:08 PM, Colnet Dominique wrote:
> Peter Gummer wrote:
>>> From: Colnet Dominique <[email protected]>
>>>> But ETL3 page 679 currently also says, "Depending on a global 
>>>> setting that you can override through a compilation option, INTEGER 
>>>> is a synonym for either INTEGER_32 or INTEGER_64." ...
>>> I have reported the problem to ECMA a long time ago. At time being, 
>>> they have decided to rely on a compiler flag. I don't agree with 
>>> that.
>> I don't see it as a problem. The worst thing that will happen is a 
>> compilation error. This will be a nuisance, but it would be easily 
>> fixed.
> Another problem is that you cannot mix two libraries in the same 
> system when one needs 32 INTEGERs while the other needs 64 bit 
> INTEGERs.
> The ECMA decision promotes incompatibilities :-(

That's a complication, but it doesn't seem insurmountable.

Emmanuel Stapf actually mentioned this problem on the Eiffel Software 
mailing list a couple of days ago. He says that they are thinking of 
making the switch at the library level rather than at the project level 
to avoid the problem. They haven't implemented this yet, so it will be 
interesting to see what they come up with.

Given that SmartEiffel seems to be diverging from the draft ECMA 
standard on this issue, I wonder if Eiffel will evolve -- subsequent to 
completion of the standard -- towards something like what Richard 
O'Keefe proposed here a few days ago. The ECMA approach is very similar 
to C's. I guess this is guaranteed to efficient, without requiring a 
lot of research, and without looking frightening to the majority of 
potential Eiffel converts out there. But once the ECMA dust has 
settled, it would be nice if this issue could be revisited.

- Peter Gummer