adimetrius wrote: The type of a real constant is SHORTREAL if the constant value belongs to SHORTREAL, or REAL otherwise (see 6.1). .
While I agree that the Language Report does not seem to clearly describe the BBox compiler behaviour (and I don't want the behaviour changed) the above suggestion does not capture the (deliberately)
ambiguous behaviour of the compiler.
Consider
Code: Select all
PROCEDURE Do*;
CONST
k = 1. / 3.;
VAR
s : SHORTREAL;
r : REAL;
BEGIN
s := k;
r := k;
Out.Real (s, 15); Out.Ln;
Out.Real (r, 15); Out.Ln;
END Do;
Results:
0.3333333432674408
0.3333333333333333
k
both behaves like a SHORTREAL as it can be assigned to s, and as a REAL as it has 64 bits precision when assigned to r.
A true story - apologies if I have misremembered some of the details of about 20 years ago ....
I had some code rather like:
Code: Select all
CONST
pi* = 3.14159265358979323846;
rad2deg* = 180. / pi;
I used
rad2deg to convert angles in radians to degrees, and wanted to use it in both SHORTREAL and REAL expressions, and not loose precision when I didn't have to.
There was some problem prior to BlackBox 1.2 (maybe CONSTs couldn't be exported - I forget exactly what), but this capability was introduced at that time, and there was some description in some documentation - maybe the release notes - of this dual character of real constants.
But version 1.2 (was it still Oberon/F then?) introduced a curious feature. Within the defining module all was well, but in importing modules
rad2deg could only be one type which was determined by its first use.
I immediately wrote a complaining email to oms saying I disliked this decision, and it had broken backward compatibility of some of my code. They said it was not a decision, but an error, which they quickly fixed by releasing version 1.2.1.
So, while this ambiguous behaviour might not be clearly described in the Language Report, it is both deliberate, and, in my opinion, convenient.