[fpc-devel] Extended($FFFFFFFFFFFFFFFF) = -1?

[Jonas Maebe]

On 02 Mar 2014, at 14:30, Ewald wrote:

> On 01 Mar 2014, at 18:17, Jonas Maebe wrote:
> 
> Talking about principles:
> If hexadecimal is actually used to represent bit patterns (as Hans-Peter Diettrich wrote), then the decision to use a signed type here seems to violate this (represent bitpatterns) principle, since the highest bit in a signed number has a different meaning than the other bits, where in a bitpattern all bits have equal meaning.
> 
> It seems like sticking to one principle (signed integer as much as possible) actually breaks another principle (bitpattern).

Hans-Peter Diettrich is not a particular authority on FPC. Additionally, at least in Pascal hexadecimal numbers are simply another way to write numbers, next to decimal, binary and octal. In all cases, eventually bit pattern has to be interpreted, and this is what gives a meaning to the bits. There is no "raw bits without meaning" type in Pascal in general or in FPC in particular.

In the end, it all still boils down to the fact that you do not consider interpreting hexadecimal constants as int64 is appropriate/logical/good, while I think the opposite. While in theory a modeswitch could be added, requiring people to first inspect all possible mode switches that are in effect before they can know what a particular code fragment means is bad (or similarly: not being able to know what a code fragment presented in isolation means is very bad). Modeswitches that change the meaning of code as opposed to enabling/disabling certain features are very bad and should be limited to the absolute minimum.

And yes, this means that when a bad decision has been made in the past in a language's design, it is extremely hard to change it later on. That's why discussions about and implementations of new features often take so long, because once they're "out there", certain aspects are more or less cast in stone.


Jonas