[fpc-pascal] Loss of precision when using math.Max()
Wolf
wv99999 at gmail.com
Tue Jul 3 14:33:51 CEST 2018
The major shortcoming of this thread, the way I see it, is that the
answer provided explains what the compiler does, but not why the key
authors of Free Pascal have made these choices. What their choices
achieve is a substantial watering-down of what is supposedly Pascal's
most significant paradigm: strong typing. As Jim Lee points out, strong
typing does limit utility - but if utility is first concern, a weakly
typed language such as C would be more appropriate.
When looking at the (partial) disassembly of my little program, we see
to what degree the compiler writers have sacrificed strong typing:
/*a:=1;*
movb $0x1,0x22de87(%rip) # move 1 as single byte into 8 bit
wide variable A
*b:=a*(-1);*
movzbl 0x22de80(%rip),%eax # move A into register %EAX and
convert to 32 bit
neg %rax # negate what is in %EAX
mov %al,0x22de87(%rip) # extract the low 8 bit from %EAX
and store it in variable B
*writeln(b); // result: 255*/
. . .
This was compiled without any optimizations. As you can see, the
brackets are ignored, as is the fact that variables A and B were
supposed to be multiplied. In other words, the compiler has optimized
the code, where it was not supposed to do so. It has also replaced byte
typed values with longint typed values. It has taken my code and
translated it as if I had written
/ var
a: byte;
b: longint;//
//begin
a:=1;
b:=-longint(a); // convert A to a longint and negate it,
then save result in B
writeln( (Lower(b) ); // 'Lower' is a fictional typecast to
denote that I only use the %AL portion of the %EAX register for the result
end./
Which is quite a bit different from what I did program. Sorry if I am
picky here, but this is the type of bug you can expect in software if
you test using examples, and not through rigorous reasoning. And this is
the reason why the original Borland Pascal had range checking built-in.
If you activate it, the compiler does complain, both on my little
program and on Jim's.
But by now, range checking is optional, and Lazarus at least does not
even activate it by default.
But range checking is not the same as type checking, so I regard it as a
crutch, a work-around that needs to be taken because the compiler does
not adhere to (the spirit of) strong typing. And in this sense, what I
submit here represents the same issue as what is given in the subject
string if the whole thread:
Strong typing, and also readability, has been sacrificed on the altar of
utility, by using implicit type conversions.
Maybe we do get some views from the key authors of Free Pascal.
Wolf
PS.: while composing this mail, Santiago wrote: Pascal needs to break
backward compatibility to advance, that is, in fact, a new language. But
if pascal is struggling to survive, let alone a new language if you are
not mozilla, google...
In which direction should Free Pascal move - lower type (range,
overflow, memory) checking demands, with the implied additional sources
for bugs, but also better speed and shorter code, a la C, or should Free
Pascal rather take the lead and move towards safer, and more
trustworthy, code, a la Rust?
W.
On 03/07/2018 11:26, Jim Lee wrote:
>
>
>
> On 07/02/18 15:13, Wolf wrote:
>>
>> Not so long ago, Florian was proudly bragging about "Pascal does not
>> allow you to shoot yourself in the foot
>> <http://www.toodarkpark.org/computers/humor/shoot-self-in-foot.html>"
>>
>> What about this little program:
>>
>> program Project1;
>>
>> var a,b: byte;
>> begin
>> a:=1;
>> b:=a*(-1);
>> writeln(b); // result: 255
>> end.
>>
>> The result is obviously correct, given how the variables are
>> declared. But there are no compiler warnings / errors that the
>> assignment b:=a*(-1) is fishy, to put it mildly. And if you are
>> serious about strong typing, it ought to be illegal, with a suitable
>> complaint from the compiler.
>>
>> Who is shooting whom in the foot?
>>
>> Wolf
>>
>>
>>
>
> Should the compiler balk at this as well?
>
> program Project1;
>
> var a,b,c: byte;
> begin
> a:=5;
> b:=6;
> c:=a-b;
> writeln(c); // result: 255
> end.
>
> Without the implicit conversion of signed/unsigned values, the utility
> of the language is greatly diminished.
>
> -Jim
>
>
>
> _______________________________________________
> fpc-pascal maillist - fpc-pascal at lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20180704/3eaac5f9/attachment.html>
More information about the fpc-pascal
mailing list