[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