Peter Gerwinski wrote:

Where do such data types matter? Everywhere where we must set up a record type of well-known size and structure, for example when reading a binary file created by some other program,

(* Not necessarily by another program. If the file can get big, I'd want to choose the smallest possible types, anyway. *)

or when communicating with the operating system.

For this reason, the syntax must be compact, and somehow closer to the bare metal (assembler) than to the clouds (Modula). That's why I prefer `Word' here with respect to `Cardinal'. (* Another reason is that when I read `Card', I think of games, not of cardinalship. ;*)

(* And when I read "Word", I think of other things, too... *)

(Due to the need for compactness, I think my "Integer ( 8 )" notation was not the best idea. Or perhaps it was, and the programmer can define the below in his own Units?) So what about this?

Int8    Word8 = Byte
Int16   Word16
Int32   Word32
Int64   Word64

If everyone can define these types, we don't have to determine it here. You can declare "Word<n>" in your units, and I'll probably declare "Card<n>" or perhaps "Cardinal<n>" in mine...

Once more discussing subranges as an alternative: "True Pascal" does not specify the storage size, but valid values for those. So I am no more sure whether it is wise to guarantee that their size will always be the minimal one. And anyway, they are no true replacement for built-in data types of well-defined size because no programmer will write `0..$FF' everytime he wants to express that something has 8 bits. He will define his own type for this reason: "Type Byte = 0..$FF". (Note that `Byte' is built-in in GPC!) If we don't want terrible confusion among future GPC hackers, we should provide built-in types for such purposes.

But you can't predefine anything that might be needed by someone. Perhaps someone needs a type with the range 0..1234 that occupies 2 bytes...

So I'd prefer to have a way to define it by oneself. To me, the "packed" still seems the most logical thing to do: without "packed", the data are optimized for speed, with "packed" for size. So it would "only" be necessary to extend "packed" to any type (and I don't see any inherent reason why it should apply only to records and arrays).