Peter Gerwinski wrote:
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.
Agreed. And if someone wants to redeclare them for "100% silver plate compatibility", this is no problem to do. (Like in the Chief's system unit with -D_Borland_16_Bit_.)
The only question is if *in*this*special*case* also Integer should be redeclared to 16 bits. (I know this is quite unusual, but since this mode is *only* for using existing BP programs without (ideally any) changes, these programs are likely to expect integer to be 16 bit.)
Round parentheses are easiest to implement, but their syntax interferes with Schemata.
Would this a problem? It's very unlikely that someone would declare a schema called "Integer", isn't it? Such an "Integer(n)" could be a special built-in schema (special in that the "n" is not stored in the variable).
Square brackets come into mind, but they interfere with UCSD's "long integers".
<off-topic> Are these UCSD "long integers" of arbitrary size, or limited to subtypes of regular integer types? </off-topic>
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.
This is a strange case, indeed! How are they handled currently in packed record. Testing seems to show to it's 13 bits in fact.
(* The results are a bit strange. The following program gives "1299" !?! program x; type y=packed array [1..800] of $1000..$10ff; begin writeln(sizeof(y)) end. *)
I think it's ok like this. After all, if it's really for a system call or so, what sense would it make to interpret the values as $10xy if they were only stored as $xy? As a rule, one might say that the internal representation of a subrange always includes 0.
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.
Can not all machines address 1 byte? I.e., is "Byte" on some machines bigger than 1 byte (internally)? This gives real problems with binary files, doesn't it? How do such machines read single bytes from files at all?
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.
Fine! :-)
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'.
Why not! If it's documented, headers should be "easy" to convert then!
Summary and Proposal:
Let all GPC integer types like they are, and add `MedFoo' and `LongestFoo':
If you don't mind, please also add {Short,Med,Long,Longest}Card[inal].
Okay like this? Or better keep `Integer ( 8 )' (or `Integer < 8 >',
Why not, additionally! ("Integer(n)" is easier to read than "Packed 0..1 shl n-1".)
or `Integer : 8' like bit-fields in C,
"a:Integer:8" would look strange to me.
or `Integer * 1' like in FORTRAN?)
Would also look strange to me. "Integer * 2" I would understand as "twice the size of an integer", if at all...