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.
Jim Lee wrote 55 lines
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 -
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
