Hi,

consider this piece of code:

-- 8< -- snip --
type
   tA = array[0 .. 5] of byte;
   tB = array[0 .. 5] of byte;
var
   A : tA;
   B : tB;
begin
   FillChar (A, SizeOf (A), 0);
   B := A;     // <-- should by type error!
   A := tA(B);
end.
-- 8< -- snip --

It's simply a thing to make life easier especially for beginners. I don't know a real reason why the arrays shouldn't be considered equal so fpc doesn't complain either ;)

Well, maybe my opinion doesn't count too much (because I am an Ada-zealot where even integer types are not necessarily type-compatible), but IMO _especially_ beginners should be taught about the virtues of strong typing.

I don't know a real reason why the arrays shouldn't be considered equal

Maybe because they are used to denote completely different things? To show you the definitions from the actual code:

|type
|   tCorr_Table = packed array[byte] of Interfaces.Unsigned_8;
|   tGrad_Table = packed array[byte] of Interfaces.Unsigned_8;
|   tTimer_Ramp = packed array[byte] of Interfaces.Unsigned_16;

tCorr_Table is an array which is used to "linearize" a DAC output, while Grad_Table is simply a lookup for byte values to be used (call it translation table if you like). Both are applied to different DACs and in fact - they are completely different things and that's why I used different type declarations.

Types are most often abstractions of real world things, which you simply don't want to intermix.

Unfortunately I needed both inside a routine and swapped them in the procedure call (it doesn't matter that this time I did it on purpose to see if the compiler complains - that's why I detected this).

Oh and BTW, a few months ago

|type
|   tTd_Ramp = array[0 .. 1023] of Interfaces.Unsigned_16;

was "structural identical" with the thing called tTimer_Ramp. And although it still does the same thing as before, it is now not "type compatible" anymore (what it should have never been IMO). Nothing has changed but the type declaration.

I mean, I don't use types "just for fun". I use them for two reasons: One: To make the meaning of things more clear and
Two: to protect me against my own stupidity with the help of the compiler.

so fpc doesn't complain either ;)

Well, so why does it complain on record types that are "structurally identical"? To quote you slightly modified: "I don't know a real reason why the structures shouldn't be considered equal".

In the end it's quite simple: If I don't want the types to be different I don't declare them that way.

So what's your suggestion? To use $MODE DELPHI instead of $MODE OBJFPC if I need exceptions, too?

Vinzent.

On Monday 25 April 2005 12:10, Florian Klaempfl wrote:

Just a small reprise on this matter:

It's simply a thing to make life easier especially for beginners.

Easy to shoot theirselves in the foot? ;-) There's already a language well known for this type of "easyness".

I don't know a real reason why the arrays shouldn't be considered equal

Let me put in this way: Perhaps because your compiler is supposed to be a Pascal-compiler and Pascal considers type as identical when they are identical by name (which basically means: they derive from the same type definition) and not by structure (which can be just pure coincidence)?

I don't mean to be rude, but IMO you've did the equivalent of taking a sawed-off shotgun and blowing a big hole into Pascal's intended type system (which already isn't perfect either) - and your argument why you did it is totally bogus, because the only time where this matters is when someone uses anonymous types and their use should be strongly discouraged anyway.

Vinzent.

I usually don't say anything, but I wanted to throw my opinion on this as well. This is important to me as someone who likes Pascal as a learning tool (teaching tool), and as a language which adheres to certain ideals. I use FPC in standard mode--is it still going to let me mix types like that? If so, I'd like to see the type checking to be stronger too. I think it's ok to allow switches to turn this off, but FP should be Pascal by default.

Angelo

I agree with you Angelo. I would have responded to the thread earlier but I decided to do some research first by investigating the ISO 7185 Standard Pascal. IMHO we need to adhere to standard as much as possible and strong type checking is an integral part of the standard.

I do not agree with Florian's comment:
"It's simply a thing to make life easier especially for beginners."

Like Vinzent I can number many reasons why arrays should not be considered equal.

Arrays can be considered equal iff they are declared the same type eg.:

type
   tA, tB = array[0..5] of byte;
var
  A : tA;
  B : tB;
   ...
begin
	....
    B := A;      // valid assignment

and not equal if:

type
   tA = array[0..5] of byte;
   tB = array[0..5] of byte;
var
   A : tA;
   B : tB;
   ...
begin
	....
    B := A;      // invalid assignment

In the second case the two arrays maybe equal but iff the data are compared for equality.

Regards

John

On Monday 25 April 2005 12:10, Florian Klaempfl wrote:

I hate to possibly annoy someone here, but I didn't get an answer yet, if this will be fixed or not...

It's simply a thing to make life easier especially for beginners. I don't know a real reason why the arrays shouldn't be considered equal so fpc doesn't complain either ;)

Well, I just found the perfect reference for my argument. Your own compiler documentation:

<http://www.freepascal.org/docs-html/user/userse66.html#x92-179000C.4>

|Error: Incompatible types: got ”arg1” expected ”arg2” |There is no conversion possible between the two types Another |possiblity is that they are declared in different declarations: |
| Var  
|    A1 : Array[1..10] Of Integer;  
|    A2 : Array[1..10] Of Integer;  
|  
| Begin  
|    A1:=A2; { This statement gives also this error, it   |              is due the strict type checking of pascal }   | End.  

No more questions, your honor. Case closed. ;-)

Regards,

Vinzent.