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@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

_______________________________________________
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Reply via email to