Why are types sometimes interchangeable

[Joanna]

I hope it’s not too much of a bother. A non pascal using friend of mine wants to know why two identical real types he created are interchangeable. I told him that that isn’t the way to distinguish things but here is his question if anyone cares to answer.

Code: Pascal  [Select][+][-]

1. { It has come to my attention that unfortunately base data formats are conflated:}
2.  
3. program typeDemo(input, output, stderr);
4.  
5. type meters = real;
6. type seconds = real;
7.  
8. var l1: meters;
9. var t1: seconds;
10.  
11. begin
12.         t1 := 10.0;
13.         l1 := t1;
14. end.
15.  
16. {Well I didn't *want* this to compile.
17. But OK then, this must mean Pascal uses structural typing.
18. Therefore, two records with the same fields will be compatible:
19. }
20. program typeDemo(input, output, stderr);
21.  
22. type vector = record                                                                                                    
23.     x: real;                                                                                                            
24.     y: real;                                                                                                            
25. end;                                                                                                                    
26. type coords = record                                                                                                    
27.     x: real;                                                                                                            
28.     y: real;                                                                                                            
29. end;
30.  
31. var v1: vector;
32. var c1: coords;
33.  
34. begin
35.         // there are no records initializers or what? anyway.
36.         v1.x := 10.0;
37.         v1.y := 5.0;
38.  
39.         c1 := v1;
40. end.
41.  
42. {Well, this time around we get nominal typing. How much more random can this type system get?}

He seems to think because two simple types are considered compatible, two records with identical fields should be compatible. How do I explain this to him? My first urge is to say something along the lines of the record fields are more hidden than the type of real.

[ccrause]

Code: Pascal  [Select][+][-]

1. type meters = real;
2. type seconds = real;

Here meters and seconds are declared as type aliases to the type real.  Read the section on type aliases in the documentation for reference.

To create distinct new types, use the form:

Code: Pascal  [Select][+][-]

1. type meters = type real;
2. type seconds = type real;

This will however still be assignment compatible types, so would not generate a compiler error when mixing these types in an expression.

[440bx]

He seems to think because two simple types are considered compatible, two records with identical fields should be compatible. How do I explain this to him? My first urge is to say something along the lines of the record fields are more hidden than the type of real.

record fields aren't "more hidden" than anything else.

what happens in the case of

Code: Pascal  [Select][+][-]

1. type meters = real;
2. type seconds = real;
3.  
4. var l1: meters;
5. var t1: seconds;
6.  

is that the variables l1 and t1 ultimately both resolve to "real" which is an "atomic" pre-defined type that cannot be broken down any further (unlike "meters" and "seconds", which are really just aliases for "real" as @ccrause already pointed out)

what happens in the case of

Code: Pascal  [Select][+][-]

1.  
2. type vector = record                                                                                                    
3.     x: real;                                                                                                            
4.     y: real;                                                                                                            
5. end;                                                                                                                    
6.  
7. type coords = record                                                                                                    
8.     x: real;                                                                                                            
9.     y: real;                                                                                                            
10. end;
11.  
12. var v1: vector;
13. var c1: coords;
14.  

is that the types "vector" and "coords" are themselves atomic by virtue of being records.  A record type definition always defines an atomic type (as in the case of "vector", "coord" or whatever other name is assigned to the type)

When the parser sees that "v1" is of type "vector" and "c1" is of type " coords", it does NOT care that the fields that make up both records are the same, that is completely irrelevant.  As far as the parser is concerned, there is a type named "vector" and another type named "coords", because these are records, the different names, which implies different types, means the types are not compatible.  For type identification purposes, "vector" and "coords" are atomic and as different as "integer" is from "string" is from "set" is from an enumeration, etc, etc.

succinctly, the type of a record isn't determined by the fields it contains but by its name (which is effectively the name of a new type that is assignment compatible only with itself.)

HTH.

[Joanna]

Here meters and seconds are declared as type aliases to the type real.   

Exactly, that’s what I thought when I first saw them, of course they are the same type because they are both type real by different names. 

the variables l1 and t1 ultimately both resolve to "real" which is an "atomic" pre-defined type that cannot be broken down any further.

the types "vector" and "coords" are themselves atomic by virtue of being records

I was not familiar with the term atomic before. Thanks for teaching me something new today. I didn’t know the correct terminology to use for this.

[MarkMLl]

I've been trying, without success, to find a remark from PascalDragon when I was complaining about something-or-other a few weeks ago. Basically, his point was that there were certain number-like types that the compiler automatically treated as compatible (i.e. a byte can be assigned to a word and so on), but this didn't extend to programmer-defined types.

Hence I think it's reasonable to say that even if (from OP) meters were single and seconds were double, they would probably be compatible. Whether this is a Good Thing is arguable: it's very convenient in terms of having Pascal be a general-purpose application language, but detracts from Pascal's claim to be suitable for maximally-robust code.

I'd add that I'm not entirely happy with the term "atomic" used earlier in this thread. It's usually applied to /operations/ rather than /types/, so one would refer to a debit-this-and-credit-that operation being atomic in commerce, or a 64-bit increment being atomic if it were resistant to being broken into (by an interrupt or second CPU) when half-completed.

MarkMLl

[ctk]

Hi, I'm the one who made the initial remark.
I'm not certain why Joanna meant to make it a question of sorts, as it's only an observation. And a reason I don't see Pascal as a usable language, due to warts (such as this one) in its featureset.
Pascal will not be fixed anyway, as it is set in stone now, so the best I can hope is its users will move on to better-designed languages, after acquiring a sense for what good design is. (which my posting here might help with)

So here's the problem explained, take two:
In Pascal, I have two options to declare a new type.

I can do an alias, which does nothing but add a name for the same type:

Code: Pascal  [Select][+][-]

1. program typeDemo(input, output, stderr);
2.  
3. type vector = record
4.         x: real;
5.         y: real;
6. end;
7. type coords = vector;
8.  
9. var v1: vector;
10. var c1: coords;
11.  
12. begin
13.         // there are no record initializers or what? nevermind, let's do it field by field.
14.         v1.x := 10.0;
15.         v1.y := 5.0;
16.  
17.         c1 := v1;
18. end.

(This compiles; great! That's what was expected, and what I needed.)

Alternatively, I can declare an entirely new type from an existing one:

Code: Pascal  [Select][+][-]

1. program typeDemo(input, output, stderr);
2.  
3. type vector = record
4.         x: real;
5.         y: real;
6. end;
7. type coords = type vector; // note that I added 'type' here
8.  
9. var v1: vector;
10. var c1: coords;
11.  
12. begin
13.         // there are no record initializers or what? nevermind, let's do it field by field.
14.         v1.x := 10.0;
15.         v1.y := 5.0;
16.  
17.         c1 := v1;
18. end.

(This fails to compile; great! That's what was expected, and what I needed.)


And of course I can do the same thing with any other type, so:

Let's do an alias again:

Code: Pascal  [Select][+][-]

1. program typeDemo(input, output, stderr);
2.  
3. type meters = type real;
4. type seconds = meters;
5.  
6. var l1: meters;
7. var t1: seconds;
8.  
9. begin
10.         t1 := 10.0;
11.         l1 := t1;
12. end.

(This compiles; great! That's what was expected, and what I needed.)


And now I want these to be incompatible, so I add 'type':
(I badly need a compiler error if I ever assign seconds to meters, say if I'm a physicist)

Code: Pascal  [Select][+][-]

1. program typeDemo(input, output, stderr);
2.  
3. type meters = type real;
4. type seconds = type meters; // note that I added 'type' here
5.  
6. var l1: meters;
7. var t1: seconds;
8.  
9. begin
10.         t1 := 10.0;
11.         l1 := t1;
12. end.

This compiles; what gives?! That's completely unexpected, adding 'type' didn't have its effect. In fact it seems to have had no useful effect whatsoever.

It worked with some other type earlier, so this is inconsistent and arbitrary.
Features should work uniformly. https://en.wikipedia.org/wiki/Principle_of_least_astonishment

[MarkMLl]

@ctk: frankly, I agree with you. I've previously remarked that Pascal was, for various reasons, rushed; it was knocked together not long after Hoare and Wirth had started working on the concept of distinct types and Wirth's subsequent languages were far stricter.

MarkMLl

[Thaddy]

From the wiki:"You want to do this, for instance in order to define a whole new set of operators. Otherwise the operator definitions for the type it was cloned from would still apply."
And the manual: https://www.freepascal.org/docs-html/ref/refse19.html#x49-690003.8
The latter explains that type Tx = type y generates different RTTI so creates a means to identify a typed type.
This is also used inside the rtl and possibly the compiler. (And Delphi compatible)

It may seem a bit shallow, but it's not.

[Bogen85]

Pascal will not be fixed anyway, as it is set in stone now, so the best I can hope is its users will move on to better-designed languages, after acquiring a sense for what good design is. (which my posting here might help with)

I understand where you are coming from. There are many things in Pascal that I don't like. And I'm aware of and know many other languages (some very well, and I do use them where it is applicable).

However, there are many things I prefer to do in Pascal, by choice, despite the many shortcomings it has.

And now I want these to be incompatible, so I add 'type':
(I badly need a compiler error if I ever assign seconds to meters, say if I'm a physicist)

Code: Pascal  [Select][+][-]

1. program typeDemo(input, output, stderr);
2.  
3. type meters = type real;
4. type seconds = type meters; // note that I added 'type' here
5.  
6. var l1: meters;
7. var t1: seconds;
8.  
9. begin
10.         t1 := 10.0;
11.         l1 := t1;
12. end.

This compiles; what gives?! That's completely unexpected, adding 'type' didn't have its effect. In fact it seems to have had no useful effect whatsoever.

It worked with some other type earlier, so this is inconsistent and arbitrary.
Features should work uniformly. https://en.wikipedia.org/wiki/Principle_of_least_astonishment

I agree with you, and this is one of the things I do not like about Pascal.

However, if I needed to have Pascal enforce types in this way, that can still be done. Not at the base type level like you are showing here, but via classes or advanced records with overloaded operators and properties.

That way I segregate the different units that share the same base types but since I've hidden access to them directly, the compiler will do the enforcement you (and I) would be looking for.

[MarkMLl]

However, if I needed to have Pascal enforce types in this way, that can still be done. Not at the base type level like you are showing here, but via classes or advanced records with overloaded operators and properties.

In Wirth's defence, the idea of having distinct types for numerics etc. that were structurally compatible was very much a novel one. While (even in the ALGOL-60 era) people appreciated that reals were distinct from integers and integers were distinct from strings (and all three were often handled by distinct areas of the CPU), the idea that two reals were not assignment-compatible might even have made it more difficult to sell the idea of block-structured languages than it was already.

MarkMLl

[440bx]

I'd add that I'm not entirely happy with the term "atomic" used earlier in this thread. It's usually applied to /operations/ rather than /types/, so one would refer to a debit-this-and-credit-that operation being atomic in commerce, or a 64-bit increment being atomic if it were resistant to being broken into (by an interrupt or second CPU) when half-completed.

MarkMLl

I'm not particularly fond of using the term "atomic" to describe a data type.  I used that term because when the parser is going through its tables to determine the final/true type (which it needs to do), when it finds that something is a "record", the search stops.  It's a record, that's it.   

In the case of an alias, such as "type coords = real;", there will often be a pointer (or some indicator) that "coords" resolves to one of the language's standard/built-in types thus the search can be thought of having gone one more step (thereby "coords" is not "atomic")

I agree the terminology is not quite ideal.

[MarkMLl]

I'm not particularly fond of using the term "atomic" to describe a data type.  I used that term because when the parser is going through its tables to determine the final/true type (which it needs to do), when it finds that something is a "record", the search stops.  It's a record, that's it.   

Hmm. "Terminal something"... just calling it a terminal would be confusing in the larger compiler context since that's how predefined keywords are referred to. "Terminal type"?

Whatever: I see what you're getting at. It's not just "this is an lvalue" or "this is a variable being used in an expression", it's having progressed sufficiently in examination of the type of the variable that its constituent parts aren't relevant.

MarkMLl

[Joanna]

(I badly need a compiler error if I ever assign seconds to meters, say if I'm a physicist)

This reminds me of back when I was taking a beginning computer Programming class when the teacher was explaining that computers are dumb and don’t know anything.
Meters and seconds mean nothing to a computer and it’s the responsibility of the programmer not to add meters to seconds or any other inappropriate things of same data type for that matter.

It would be ridiculous to make a new data type for every simple Numerical variable that shouldn’t be added together.

The workaround would be to encapsulate the meters and seconds As fields inside of separate records. I suppose you would need to make procedures To do math on them because they are inside records. Robustness is possible but it always takes a lot of extra effort to achieve it in any circumstance.

I don't see Pascal as a usable language, due to warts (such as this one) in its featureset.
Pascal will not be fixed anyway, as it is set in stone now, so the best I can hope is its users will move on to better-designed languages, after acquiring a sense for what good design is. (which my posting here might help with)

It doesn’t need fixing 
This is a prime example of the hostility to pascal I encounter from people who don’t use pascal. There is nothing wrong with pascal in this regard. I have been using it a long long time and it keeps getting better. Some people will just go to great lengths make up excuses not to use it as illustrated here.

[lainz]

And how it works in another languages to compare with fpc? For example in c or c++?

[Joanna]

Someone just mentioned to me that although meters and seconds don’t add what about computing meters per second? Should that be allowed? I suppose we need a better fpc compiler that will only allow meters to be divided by seconds but prevent all other mathematical operations