Hello, everybody!

I am trying now to summarize our "Integer type" problems and to propose a solution.

Problem #1: Compatibility to BP.

- Some people want `Word' to have 16 bits, because it has in BP. - Some other people want `Word' to have the same size as `Integer', because it has in BP. - Some people expect `LongInt' to have 32 bits, like in BP. - Some other people expect `LongInt' to be bigger than `Integer', like in BP.

Hard to escape!

Problem #2: Data types with known size.

Here everybody seems to agree that they are needed, discussions are about how they should be named.

- `int8' and `card8' - `int8' and `word8' - `Integer ( 8 )' and `Cardinal ( 8 )' and/or `Word ( 8 )' - `0..$FF' (always) - `packed 0..$FF'

There is also need for a data type which is guaranteed to be the largest signed/unsigned Integer type available.

Problem #3: Compatibility to GCC.

In order to access libraries written in GCC, GPC must provide integer types which are guaranteed to be the same as `long long unsigned int' etc. in GCC.

- Current implementation:

GPC GCC ByteInt Byte signed char unsigned char ShortInt ShortWord short unsigned short Integer Word int unsigned LongInt = Comp LongWord long long unsigned long long

Obviously, an equivalent for GCC's `[unsigned] long' is missing. This is because it's the same as `[unsigned] int'. If we can make sure that this will always be the case, we can safely leave things like they are and document them (which I already did: see "info -f gpc -n Integer").

- Some people propose to change `LongInt' to be the same as GCC's `long'. Advantage: closer to GCC's syntax, and same bit size as BP's `LongInt'. Disadvantage: `LongInt' would not be longer than `Integer'.

- While we are discussing all this, GPC already has type modifiers: `__long__ Integer' means the same as `long' in GCC. So there *is* a mechanism with syntax close to C which guarantees compatibility.

(* If we were Borland, we would probably say now: "On all currently existing platforms, GCC's `long' is the same as `int', so don't worry about the missing equivalent for `long'." *)

Discussion of #1: Compatibility to BP.

- GPC is *not* intended to be a drop-in replacement for BP. Compatibility is desireable as long as we don't have to pay a high price for it. We want to preserve the "spirit" of BP in GPC, not its "letters". What we do is to "write BP, as it should have been", not "rewrite BP, exactly as it is".

- GPC is a 32-bit compiler. Maybe we will extend it to 64 bits, some day, but we won't restrict it to 16 bits.

That's why `Word' etc. are as they are, and why I think they should not change.

Discussion of #2: Data types with known size.

I think, Frank is right when he says that we must provide a way to define them rather than defining everything in GPC.

Separate identifiers for everything are not flexible enough.

Round parentheses are easiest to implement, but their syntax interferes with Schemata. Square brackets come into mind, but they interfere with UCSD's "long integers".

While the remaining two possibilities are certainly the most `Pascalish' ones, they are not 100% clear: What size has `packed $1000..$10FF'? Although 8 bits would be sufficient, GPC would allocate 13 bits. Outside of packed arrays and records, they would be rounded to the next unit the machine can access, usually 8 bits, but it can also be 16 or 32 bits.

Despite of the disadvantage sketched above, I think that `packed 0..$FF' is the way to go. Authors of libraries are encouraged to define their own types using this mechanism.

To have `LongestInt' as - currently - a synonym for `LongInt' cannot hurt. If one day there will be something longer than `LongInt', we can name it `LongLongInt' (because it might be superseeded again by `LongLongLongInt'), but `LongestInt' will always remain the longest one.

Discussion of #3: Compatibility to GCC.

I can guarantee that the above GPC <--> GCC compatibility rules for `ShortInt' etc. will not change. Then the only needed thing is something which is guaranteed to be the same as `long' in GCC, even if `int' is not the same as `long'. Since we are aiming towards the top, C's `long' is just "medium" for us. ;-) Thus I propose the names `MedInt' and `MedWord'.

Summary and Proposal:

Let all GPC integer types like they are, and add `MedFoo' and `LongestFoo':

GPC GCC ByteInt Byte signed char unsigned char ShortInt ShortWord short unsigned short Integer Word int unsigned MedInt MedWord long unsigned long LongInt = Comp LongWord long long unsigned long long LongestInt LongestWord long long unsigned long long

where `MedInt' happens to be the same as `Integer' and `MedWord' the same as `Word' on all platforms currently existing.

Introduce `packed 0..$FF' like discussed above.

Forget about `Integer ( 8 )'. But don't forget about UCSD's `Integer [ 42 ]' which might be implemented later.

Okay like this? Or better keep `Integer ( 8 )' (or `Integer < 8 >', or `Integer : 8' like bit-fields in C, or `Integer * 1' like in FORTRAN?) which shows more explicitly how many bits a type has?

Yours,

Peter

Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]