On 18/08/2021 20:02, Bart wrote:
> On 18/08/2021 16:16, David Brown wrote:
>> On 18/08/2021 12:59, Bart wrote:
>> int32 and uint32 are simple, clear, unambiguous, easy to type, and
>> cannot seriously be mistaken for anything else.
> int32 is OK, that's what I use mostly when I need that specific,
> narrower type.
> But I need a bigger difference between signed and unsigned integers.
> Just sticking a 'u' at the front doesn't cut it, unless it replaces 'i'
> with 'u' as happens with i32 and u32. With int32/uint32, the difference
> is too subtle, and uint is unpleasant to type.
So it is obvious to you (so obvious that you think it is universally
obvious) that "u32" is "unsigned integer 32-bit", equally obvious that
"int32" is "signed integer 32-bit", and yet "uint32" is too subtle? I
can't help feeling there is an inconsistency here somewhere...
Let's just say I think that a programming language should have one
single standard method for naming these fixed-size types. Multiple
small variations for a type whose name means basically the same thing,
and which will be used in the same circumstances, does not help anyone.
Different names with different meanings, and used in different
circumstances, are another matter - even if they happen to have the same
size in a particular use-case.
These names don't have to be keywords or fundamental types in the
language. A language could have a completely flexible system for
integer types, so that "int32" is defined in the language standard
library as "type_alias int32 = builtin::integer<4, signed>", or whatever
syntax or features you pick. But thereafter, programmers should stick
to the standard names unless they have need of a specific name for the
type. (Thus in C, the fundamental boolean type is "_Bool" - but the
standard name is "bool". And for size-specific types, you should use
"int32_t" and friends, as those are the standard names. It doesn't
matter that some people use other names, for good or bad reasons - those
are still the names you should use.)
As for the details of the names - the language designed should pick
names that he/she likes, consulting with others in the project. Then
during alpha testing they should collect feedback from other users and
interested parties who are looking at the language.
>>> word64 also has the informal, "don't care" synonym 'word' (like 'int' is
>>> a synonym for int64').
>> The trouble with "word" is the size is seriously ambiguous. I'd say it
>> is worse than "int" in that respect.
> Denotations like 'int' and 'word' are supposed to be /slightly/
> ambiguous. They are used when you don't care about the width, but expect
> the default to be sufficient.
I think it's fair to expect "int" to mean "a type meant to hold
integers". If you are used to C, or if the language is fairly low
level, you could assume it also means a small and efficient type. If
you are used to high level languages, you might take it to mean
unlimited range. But amongst anyone that has worked with low-level
programming, or who knows what processor they are targetting, "word"
means "machine word" at is tightly connected to the processor - with the
definition and size varying hugely. To someone without low-level
experience or knowledge, it might make no sense at all.
Thus I think "word" is a particularly bad choice of names - it has been
used and abused too much and has no real meaning left. I'd put it as a
lot worse than "int" in that respect.
I think there are times where a generic "number" type could be very
convenient. In simple languages with few types, it makes a lot of sense
(perhaps even more so in interpreted or bytecode-compiled languages).
Just have one type "num" that is a signed integer of the biggest size
that works efficiently for the processor. There would be no point in
having signed and unsigned versions here. This could be simple and
convenient for local variables, but I would not want to allow it for
types that are used in interfaces - you'd want it for limited scope use
where the compiler can see the ranges needed. ("int" in C is a little
like this in its original intention, but that has got lost somewhere
along the line as "int" has been used inappropriately when more tightly
specified types would be better, and as implementations have failed to
make "int" 64-bit on 64-bit systems.)
> The default on my current languages is to make then 64 bits wide, so
> it's unlikely to be insufficient.
> 40 years ago they were 16 bits, and some 20 years ago they become 32
> bits. I don't really see a need for default 128-bit integers even in 20
> years from now.
> Most languages appear to be stuck with a default 32-bit int type, which
> is now too small for memory sizes, large object sizes, file sizes and
> many other things.
32-bit is big enough for almost every situation for memory sizes, file
sizes, etc. Not /every/ situation - but almost all. But if you want a
type that can handle everything and be efficient on PC's, then 64-bit is
> As for 'word', I've used that to mean an unsigned version of 'int' since
> the 80s, although it was then 16 bits. (It still is in my x64 assembler
> in the form of DW directives and register names like W3.)
Yes, I understand that. But programming languages should not be
designed around the experiences and preferences of one single
programmer. The name "word" should not be used in a language that has
ambitions beyond a small hobby language, precisely because it means so
many different things to different people or in different contexts, and
is thus meaningless and confusing.
>> I'd be okay with "real32", "real64", etc., as well - but I think "float"
>> is more accurate (floating point numbers do not exactly represent real
>> numbers). And like "word", the name "real" is a long outdated name
>> without clear rules on its size.
> I used 'real' in Algol, Fortran and Pascal, and I've used it in my own
> languages since 1981 (when it was implemented as an f24 type). So I
> don't care that it's outdated. Just that I might need to keep explaining
> what it means!
Sometimes it is hard to be objective about things that have been
familiar for so long. I've been familiar with "real numbers" as a named
mathematical concept since I was perhaps 10 years old. So it is hard to
imagine that someone might not know what "real" means.
But it is certainly easy to imagine that the size of a type "real" is
not clearly defined - unlike "float" and "double", it has never been
standardised and different sizes of "real" have been in common use.