Bookstore

 Computer Math and Games in Pascal (preview) Lazarus Handbook

Author Topic: Type inference and constant values  (Read 1332 times)

PascalDragon

• Hero Member
• Posts: 2248
• Compiler Developer
Re: Type inference and constant values
« Reply #15 on: August 13, 2020, 01:57:11 pm »
Hands up those who've used -ve numbers in any base other than 10.

Where does -ve suddenly come from?

marcov

• Global Moderator
• Hero Member
• Posts: 8779
• FPC developer.
Re: Type inference and constant values
« Reply #16 on: August 13, 2020, 01:58:57 pm »
Probably NEGATIve sounds too negative

MarkMLl

• Hero Member
• Posts: 1319
Re: Type inference and constant values
« Reply #17 on: August 13, 2020, 02:41:41 pm »
Hands up those who've used -ve numbers in any base other than 10.

Where does -ve suddenly come from?

64-bit etc. literals being signed by default. Why not simply say that if a literal's expressed in other than base 10 that it's assumed to be unsigned, while decimals are signed?

MarkMLl
Turbo Pascal v1 on CCP/M-86, multitasking with LAN and graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.

nanobit

• Jr. Member
• Posts: 85
Re: Type inference and constant values
« Reply #18 on: August 13, 2020, 02:45:51 pm »
See left column at:

Delphi docs refer to "\$FFFFFFFFFFFFFFFF", "-\$8000000000000000" as constantExpression.
hexadecimal literal \$... is part of the constantExpression
« Last Edit: August 13, 2020, 04:04:00 pm by nanobit »

marcov

• Global Moderator
• Hero Member
• Posts: 8779
• FPC developer.
Re: Type inference and constant values
« Reply #19 on: August 13, 2020, 04:21:31 pm »
See left column at:

Delphi docs refer to "\$FFFFFFFFFFFFFFFF", "-\$8000000000000000" as constantExpression.
hexadecimal literal \$... is part of the constantExpression

Note that positive values up to 31-bit are both int64 and uint64 according to that table. It doesn't state a preference.

PascalDragon

• Hero Member
• Posts: 2248
• Compiler Developer
Re: Type inference and constant values
« Reply #20 on: August 14, 2020, 09:24:20 am »
Hands up those who've used -ve numbers in any base other than 10.

Where does -ve suddenly come from?

64-bit etc. literals being signed by default. Why not simply say that if a literal's expressed in other than base 10 that it's assumed to be unsigned, while decimals are signed?

Then you'd get the same problem as we have now, just with Int64:

Code: Pascal  [Select][+][-]
1. const
2.   MyVal: Int64 = \$FFFFFFFFFFFFFFFF;

There is currently no way for the compiler to handle this gracefully due to how these are handled and there'd always be one who'd miss out. Not to mention that this would affect backwards compatibility as right now using such a value in a function call that has both Int64 and QWord overloads would pick the signed one. In most cases that probably won't have any negative effect, but there might be.

nanobit

• Jr. Member
• Posts: 85
Re: Type inference and constant values
« Reply #21 on: August 14, 2020, 12:08:02 pm »
Whereever the target type int64 is explicit, Delphi implements implicit typecast
const MyVal: int64 = \$FFFFFFFFFFFFFFFF;  // is accepted as -1 (but warning)
const MyVal = \$FFFFFFFFFFFFFFFF;  // target type absent, needs manual correction:
const MyVal = int64(\$FFFFFFFFFFFFFFFF);

In Delphi, the implicit typecast to int64 overrules the strict range checking,
and int64 is loaded correctly. The same happens if they are no overloads:
procedure writeSomeInt( i: int64);
writeSomeInt( \$FFFFFFFFFFFFFFFF); // implicit typecast (i becomes -1)

Problems with old negative 64 bit literals occur only if target type is indefinite (overloads) or absent (thus uint64).

The porting situation is not that dramatic as it might appear at first glance.
Typical app developers (majority of Lazarus users) don't have such 64bit hex literals in their source code. More occurrences in this order: scientists, engineers, system developers and finally compiler developers because they need to cover the whole language with all edge cases. In short, compiler developers have the most work, but also the most experience with lowlevel stuff.

And it's less a decision between incompatible and compatible,
but between compatible with one side (1) or compatible with the other side (2):
1) with other languages (Delphi, ...), FPC docs (int64 literal undocumented),
logical assumptions, smooth transition to 128 bit literals, first impressions
2) old Freepascal source untyped negative 64 bit hex literals
« Last Edit: August 14, 2020, 02:12:59 pm by nanobit »