What's the best term for what might be called a null or nil pointer? In
a recent thread it turned out that there were various preferences and
various names that people are familiar with.

I am thinking to use as a keyword something like one of these:

null
nil
nullptr
ptr_null
none
empty
void
nothing
nowhere

As context imagine that you wanted to initialise a child node n with

n.left = X
n.right = X
n.data = 0

where X is one of the keywords above or some other that I've not listed.
The question is, which X would be best?

If it doesn't muddy the waters too much I should say that in addition to
'a pointer to no object' I /might/ also need a name for a pointer value
which has not been defined. If I do go that way then I'll need not one
but two names: one for a pointer which has been set to point to no
object and one for a pointer which has never been initialised. That's
why I added ptr_null into the above list - so that there would also be a
similar-looking ptr_undef or ptr_undefined. If you prefer, say, 'none'
for an explicitly set pointer to no object what name would you use for
undefined?

As a related matter, what capitalisation do you prefer for
language-defined constants such as the above and for 'true' and 'false'?
Do you prefer to see them have all lower case, all upper case, or to
capitalise just the first letter?

I know that a particular name is a minor matter but as I have to choose
I wondered what you guys find most intuitive or natural. Perhaps that
depends on whether one is thinking of the pointer or the referent. For
example, if one is thinking of the pointer then

nil

might be most natural as in "the pointer /is/ nil" whereas if one is
thinking of the referent then

nothing

may be better in the sense that "the pointer /is pointing at/ nothing".
Not sure.

Either way, how do the options look to you and what keyword or keywords
would you prefer to see in a piece of code? Also, are there any you
really dislike?!

--
James Harris

On 16/08/2021 16:37, James Harris wrote:
> What's the best term for what might be called a null or nil pointer? In
> a recent thread it turned out that there were various preferences and
> various names that people are familiar with.
>
> I am thinking to use as a keyword something like one of these:
>
>   null
>   nil
>   nullptr
>   ptr_null
>   none
>   empty
>   void
>   nothing
>   nowhere

In static code I use 'nil' as a built-in named constant of type 'ref
void' (void* in C), which is compatible with any pointer type.

There is also 'empty' and 'clear', which are interchangeable and can be
used as nouns or verbs, but only in the context of initialising a
variable or assigning to an expression; it is not a value:

int a:=empty
clear a # same as a:=empty
empty a # same as a:=empty

This was intended for array/record types, but works with any type
including pointers, where it will set them to nil.

It will clear the object to all-zeros, so nil must be all-zeros too.

In dynamic code, I also have 'void', but this simply means 'unassigned'.
All objects start off as void, but they can be set manually back to void
too:

a := 100
a := void

('void' is actually a type, but for convenience, it is treated as a
value - of type void - in source code. I have to use void.type for the
other meaning.)

>
> If it doesn't muddy the waters too much I should say that in addition to
> 'a pointer to no object' I /might/ also need a name for a pointer value
> which has not been defined.

See my 'void' above. However that only applies to dynamic code.
Elsewhere I would need to invent some suitable value:

int dummy # outside a function
ref void undefined = &dummy

ref byte p := undefined # inside a function

if p=undefined then ...

The undefined value should work for any pointer type.

> As a related matter, what capitalisation do you prefer for
> language-defined constants such as the above and for 'true' and 'false'?

That's up to my 'users'. My languages are case-insensitive, so they can
can choose truE and falsE if they like.

> I know that a particular name is a minor matter but as I have to choose
> I wondered what you guys find most intuitive or natural. Perhaps that
> depends on whether one is thinking of the pointer or the referent. For
> example, if one is thinking of the pointer then
>
>   nil
>
> might be most natural as in "the pointer /is/ nil" whereas if one is
> thinking of the referent then
>
>   nothing

You can give a choice maybe? Allow both null and nil for example.

> Either way, how do the options look to you and what keyword or keywords
> would you prefer to see in a piece of code? Also, are there any you
> really dislike?!

ptr_null

Anything with embedded underscore (shifted on my keyboard) in general.

On 16/08/2021 17:37, James Harris wrote:
> What's the best term for what might be called a null or nil pointer? In
> a recent thread it turned out that there were various preferences and
> various names that people are familiar with.
>
> I am thinking to use as a keyword something like one of these:
>
>   null
>   nil
>   nullptr
>   ptr_null
>   none
>   empty
>   void
>   nothing
>   nowhere
>
> As context imagine that you wanted to initialise a child node n with
>
>   n.left = X
>   n.right = X
>   n.data = 0
>
> where X is one of the keywords above or some other that I've not listed.
> The question is, which X would be best?
>
>
> If it doesn't muddy the waters too much I should say that in addition to
> 'a pointer to no object' I /might/ also need a name for a pointer value
> which has not been defined. If I do go that way then I'll need not one
> but two names: one for a pointer which has been set to point to no
> object and one for a pointer which has never been initialised. That's
> why I added ptr_null into the above list - so that there would also be a
> similar-looking ptr_undef or ptr_undefined. If you prefer, say, 'none'
> for an explicitly set pointer to no object what name would you use for
> undefined?
>
>

It might depend on how you use the pointer in the language. For
languages that implicitly dereference pointers to objects, something
denoting "nothing", "none", or "empty" makes sense - by writing "p =
empty" you are saying that the object referred to by "p" is empty or
non-existent. (For prior art, Python uses "None".)

For languages where you really think of "p" as a a pointer, and are
interested in the pointer rather than just the thing it points to,
something denoting "zero" is the popular choice - "null" and "nil" are
commonly used, with "null" being a little more common AFAICS. (C++ now
uses "nullptr", but that's because they needed a new name and "null" was
taken, and they didn't want something that was likely to be an existing
identifier.)

Some languages allow you to think in both ways - having both pointers
and references.

>
> As a related matter, what capitalisation do you prefer for
> language-defined constants such as the above and for 'true' and 'false'?
> Do you prefer to see them have all lower case, all upper case, or to
> capitalise just the first letter?
>

I personally dislike anything being in all-caps. I prefer keywords to
be small letters.

Sometimes a language has a system (either voluntarily by convention, or
enforced by the language) with identifiers being different categories
depending on whether they start with a capital or with a small letter.

One thing I would advise against is making a language case insensitive -
that's just a license for programmers to be inconsistent and confusing.

On 16/08/2021 17:41, Bart wrote:
> On 16/08/2021 16:37, James Harris wrote:

>> What's the best term for what might be called a null or nil pointer?

....

>> I know that a particular name is a minor matter but as I have to
>> choose I wondered what you guys find most intuitive or natural.
>> Perhaps that depends on whether one is thinking of the pointer or the
>> referent. For example, if one is thinking of the pointer then
>>
>>    nil
>>
>> might be most natural as in "the pointer /is/ nil" whereas if one is
>> thinking of the referent then
>>
>>    nothing
>
>
> You can give a choice maybe? Allow both null and nil for example.

Am not a fan of arbitrary choices. They can lead to friction if one
programmer has to maintain the code written by another and their
personal preferences differ. I think I would need to pick one word.

>
>
>> Either way, how do the options look to you and what keyword or
>> keywords would you prefer to see in a piece of code? Also, are there
>> any you really dislike?!
>
> ptr_null
>
> Anything with embedded underscore (shifted on my keyboard) in general.

OK. Is it the shift keying you don't like? I know you write expressions
with no spaces either side of operators but if

ptr-null

were a single permitted name (which didn't require shift) how would your
view change, if at all?

--
James Harris

On 17/08/2021 10:47, David Brown wrote:
> On 16/08/2021 17:37, James Harris wrote:

>> What's the best term for what might be called a null or nil pointer?

....

> It might depend on how you use the pointer in the language. For
> languages that implicitly dereference pointers to objects, something
> denoting "nothing", "none", or "empty" makes sense - by writing "p =
> empty" you are saying that the object referred to by "p" is empty or
> non-existent. (For prior art, Python uses "None".)

Maybe that's true even without automatic dereferencing. For example, in
C one might write

n->left = newnode;

where newnode is really a pointer. Correspondingly, in

n->right = Nothing

In that, Nothing would also be a pointer even though the form is
ostensibly saying that there's nothing on the right rather than that the
right-side pointer is a certain value.

>
> For languages where you really think of "p" as a a pointer, and are
> interested in the pointer rather than just the thing it points to,
> something denoting "zero" is the popular choice - "null" and "nil" are
> commonly used, with "null" being a little more common AFAICS. (C++ now
> uses "nullptr", but that's because they needed a new name and "null" was
> taken, and they didn't want something that was likely to be an existing
> identifier.)

OK.

>
> Some languages allow you to think in both ways - having both pointers
> and references.

Something to come back to!

>
>>
>> As a related matter, what capitalisation do you prefer for
>> language-defined constants such as the above and for 'true' and 'false'?
>> Do you prefer to see them have all lower case, all upper case, or to
>> capitalise just the first letter?
>>
>
> I personally dislike anything being in all-caps. I prefer keywords to
> be small letters.

OK.

It occurs to me that one area where an initial cap can be useful is when
including keywords in written text. For example, if I write that
something is False with an initial capital letter then it more clearly
shows that I am referring to a keyword rather than to a constant or a
concept. That would make the keywords

True
False
None (or Nothing or Null or Nil etc)

ISTM that (as I think you suggested) they look better than all caps.

--
James Harris

On 17/08/2021 15:28, James Harris wrote:
> On 16/08/2021 17:41, Bart wrote:
>> On 16/08/2021 16:37, James Harris wrote:
>
>>> What's the best term for what might be called a null or nil pointer?
>
> ...
>
>>> I know that a particular name is a minor matter but as I have to
>>> choose I wondered what you guys find most intuitive or natural.
>>> Perhaps that depends on whether one is thinking of the pointer or the
>>> referent. For example, if one is thinking of the pointer then
>>>
>>>    nil
>>>
>>> might be most natural as in "the pointer /is/ nil" whereas if one is
>>> thinking of the referent then
>>>
>>>    nothing
>>
>>
>> You can give a choice maybe? Allow both null and nil for example.
>
> Am not a fan of arbitrary choices. They can lead to friction if one
> programmer has to maintain the code written by another and their
> personal preferences differ. I think I would need to pick one word.

C allows both NULL and 0. Plus any expression that yields 0.

>>
>>
>>> Either way, how do the options look to you and what keyword or
>>> keywords would you prefer to see in a piece of code? Also, are there
>>> any you really dislike?!
>>
>> ptr_null
>>
>> Anything with embedded underscore (shifted on my keyboard) in general.
>
> OK. Is it the shift keying you don't like? I know you write expressions
> with no spaces either side of operators but if
>
>   ptr-null
>
> were a single permitted name (which didn't require shift) how would your
> view change, if at all?

ptr-null is better. Although I'd start wondering why you need the 'ptr'
part, if 'null' is not used in other contexts.

On 17/08/2021 16:51, Bart wrote:
> On 17/08/2021 15:28, James Harris wrote:
>> On 16/08/2021 17:41, Bart wrote:
>>> On 16/08/2021 16:37, James Harris wrote:

>>>> What's the best term for what might be called a null or nil pointer?

....

>>> You can give a choice maybe? Allow both null and nil for example.
>>
>> Am not a fan of arbitrary choices. They can lead to friction if one
>> programmer has to maintain the code written by another and their
>> personal preferences differ. I think I would need to pick one word.
>
> C allows both NULL and 0. Plus any expression that yields 0.

Indeed, though I'm not planning to copy that approach. I'd probably
prohibit comparisons against zero. Something like the following.

if p eq 0 [prohibited]
if p eq Undef
if p eq Nil
if p [true if p is valid (i.e. neither Undef nor Nil)]

In those, Undef would be all-bits-zero but would be of a type which
could be compared against a pointer whereas an integer could not.
Further, if p were to be converted to False/True as in the last line
then False would mean "either Undef or Nil".

This is all speculation at the moment. Am just throwing around some ideas.

>
>>>
>>>> Either way, how do the options look to you and what keyword or
>>>> keywords would you prefer to see in a piece of code? Also, are there
>>>> any you really dislike?!
>>>
>>> ptr_null
>>>
>>> Anything with embedded underscore (shifted on my keyboard) in general.
>>
>> OK. Is it the shift keying you don't like? I know you write
>> expressions with no spaces either side of operators but if
>>
>>    ptr-null
>>
>> were a single permitted name (which didn't require shift) how would
>> your view change, if at all?
>
> ptr-null is better.

OK.

>
> Although I'd start wondering why you need the 'ptr'
> part, if 'null' is not used in other contexts.

I was thinking that if I had more than one reserved pointer value that
it may be better to give them a common form. Instead of, for example,

Undef
Nil

there would be

ptr-undef
ptr-nil

That would conceptually group similar constants together and take fewer
words away from those the programmer could define.

If there ends up being just one reserved pointer value then it would not
be a good idea.

If there end up being just two reserved pointer values then it may or
may not be worth it.

But if I were to end up adding a number of other reserved pointer values
then it might be better for the language overall if they were to have a
common appearance.

--
James Harris

On 17/08/2021 17:51, Bart wrote:
> On 17/08/2021 15:28, James Harris wrote:
>> On 16/08/2021 17:41, Bart wrote:
>>> On 16/08/2021 16:37, James Harris wrote:
>>
>>>> What's the best term for what might be called a null or nil pointer?
>>
>> ...
>>
>>>> I know that a particular name is a minor matter but as I have to
>>>> choose I wondered what you guys find most intuitive or natural.
>>>> Perhaps that depends on whether one is thinking of the pointer or
>>>> the referent. For example, if one is thinking of the pointer then
>>>>
>>>>    nil
>>>>
>>>> might be most natural as in "the pointer /is/ nil" whereas if one is
>>>> thinking of the referent then
>>>>
>>>>    nothing
>>>
>>>
>>> You can give a choice maybe? Allow both null and nil for example.
>>
>> Am not a fan of arbitrary choices. They can lead to friction if one
>> programmer has to maintain the code written by another and their
>> personal preferences differ. I think I would need to pick one word.
>
> C allows both NULL and 0. Plus any expression that yields 0.
>

/Every/ language allows arbitrary choices in all sorts of places. That
does not mean you have to encourage it from the outset. James is right
here - it matters little whether he picks "null" or "nil", but either is
far better than having both.

>>>
>>>
>>>> Either way, how do the options look to you and what keyword or
>>>> keywords would you prefer to see in a piece of code? Also, are there
>>>> any you really dislike?!
>>>
>>> ptr_null
>>>
>>> Anything with embedded underscore (shifted on my keyboard) in general.
>>
>> OK. Is it the shift keying you don't like? I know you write
>> expressions with no spaces either side of operators but if
>>
>>    ptr-null
>>
>> were a single permitted name (which didn't require shift) how would
>> your view change, if at all?
>
> ptr-null is better. Although I'd start wondering why you need the 'ptr'
> part, if 'null' is not used in other contexts.
>

Programmers read code far more than they type it. If the programming
language designer here thinks "ptr_null" is the clearest way for a null
pointer to be expressed in the language, then that preference totally
dominates over one single person's complaints about the hardships of
using the shift key.

And Bart, if underscore is so diffult for you (perhaps you have
arthritis or other challenges), I'd recommend looking at different
keyboards, or enabling "sticky shift keys" or similar aids supported by
your OS of choice.

Certainly the use of "shift" is not relevant to language design.

On 17/08/2021 17:56, David Brown wrote:
> On 17/08/2021 17:51, Bart wrote:
>> On 17/08/2021 15:28, James Harris wrote:
>>> On 16/08/2021 17:41, Bart wrote:
>>>> On 16/08/2021 16:37, James Harris wrote:
>>>
>>>>> What's the best term for what might be called a null or nil pointer?
>>>
>>> ...
>>>
>>>>> I know that a particular name is a minor matter but as I have to
>>>>> choose I wondered what you guys find most intuitive or natural.
>>>>> Perhaps that depends on whether one is thinking of the pointer or
>>>>> the referent. For example, if one is thinking of the pointer then
>>>>>
>>>>>    nil
>>>>>
>>>>> might be most natural as in "the pointer /is/ nil" whereas if one is
>>>>> thinking of the referent then
>>>>>
>>>>>    nothing
>>>>
>>>>
>>>> You can give a choice maybe? Allow both null and nil for example.
>>>
>>> Am not a fan of arbitrary choices. They can lead to friction if one
>>> programmer has to maintain the code written by another and their
>>> personal preferences differ. I think I would need to pick one word.
>>
>> C allows both NULL and 0. Plus any expression that yields 0.
>>
>
> /Every/ language allows arbitrary choices in all sorts of places. That
> does not mean you have to encourage it from the outset. James is right
> here - it matters little whether he picks "null" or "nil", but either is
> far better than having both.

I sometimes allow a choice if I can't make up my mind about a feature or
a keyword. Then I can try it out and see which one feels better or looks
better, or which is used more often. Or I might use one form privately,
and another for shared code.

Here however, both null and nil are commonly used in programming
languages for the same thing. So why not allow both? If someone uses two
languages, one uses NULL, the other nil, if would be really convenient
to not have to keep thinking about which one you should be using.

(Although having said that, mine don't allow null! But then I am the
only user.)

>
> And Bart, if underscore is so diffult for you (perhaps you have
> arthritis or other challenges), I'd recommend looking at different
> keyboards, or enabling "sticky shift keys" or similar aids supported by
> your OS of choice.
>
> Certainly the use of "shift" is not relevant to language design.

Simplest of all is having alphunumeric identifiers not requiring you to
pause in the middle to deal with case or shift changes.

This especially applies to keywords that you can't do anything about.

So I'd say it's very relevant to not having a language that is a pita to
use.

On 17/08/2021 16:43, James Harris wrote:
> On 17/08/2021 10:47, David Brown wrote:
>> On 16/08/2021 17:37, James Harris wrote:
>

>>> As a related matter, what capitalisation do you prefer for
>>> language-defined constants such as the above and for 'true' and 'false'?
>>> Do you prefer to see them have all lower case, all upper case, or to
>>> capitalise just the first letter?
>>>
>>
>> I personally dislike anything being in all-caps.  I prefer keywords to
>> be small letters.
>
> OK.
>
> It occurs to me that one area where an initial cap can be useful is when
> including keywords in written text. For example, if I write that
> something is False with an initial capital letter then it more clearly
> shows that I am referring to a keyword rather than to a constant or a
> concept. That would make the keywords
>
>   True
>   False
>   None (or Nothing or Null or Nil etc)
>
> ISTM that (as I think you suggested) they look better than all caps.
>
>

I do think "True" is better than "TRUE". But I think "true" is best :-)

Initial capitals won't mark a keyword unless you use capitals for /all/
keywords, and that will quickly get tedious and ugly. It's better to
use syntax highlighting in an editor that will mark the keywords in some
way (such as bold, or a particular colour). When writing code by hand,
I usually underline the keywords for clarity - but I wouldn't want to
use initial capitals.

On 17/08/2021 22:00, Bart wrote:
> On 17/08/2021 17:56, David Brown wrote:
>> On 17/08/2021 17:51, Bart wrote:
>>> On 17/08/2021 15:28, James Harris wrote:
>>>> On 16/08/2021 17:41, Bart wrote:
>>>>> On 16/08/2021 16:37, James Harris wrote:
>>>>
>>>>>> What's the best term for what might be called a null or nil pointer?
>>>>
>>>> ...
>>>>
>>>>>> I know that a particular name is a minor matter but as I have to
>>>>>> choose I wondered what you guys find most intuitive or natural.
>>>>>> Perhaps that depends on whether one is thinking of the pointer or
>>>>>> the referent. For example, if one is thinking of the pointer then
>>>>>>
>>>>>>     nil
>>>>>>
>>>>>> might be most natural as in "the pointer /is/ nil" whereas if one is
>>>>>> thinking of the referent then
>>>>>>
>>>>>>     nothing
>>>>>
>>>>>
>>>>> You can give a choice maybe? Allow both null and nil for example.
>>>>
>>>> Am not a fan of arbitrary choices. They can lead to friction if one
>>>> programmer has to maintain the code written by another and their
>>>> personal preferences differ. I think I would need to pick one word.
>>>
>>> C allows both NULL and 0. Plus any expression that yields 0.
>>>
>>
>> /Every/ language allows arbitrary choices in all sorts of places.  That
>> does not mean you have to encourage it from the outset.  James is right
>> here - it matters little whether he picks "null" or "nil", but either is
>> far better than having both.
>
> I sometimes allow a choice if I can't make up my mind about a feature or
> a keyword. Then I can try it out and see which one feels better or looks
> better, or which is used more often. Or I might use one form privately,
> and another for shared code.

Keeping the choice open while prototyping, developing and testing makes
sense - that's fair enough. But once your language has solidified
somewhat, then it's good to fix these things. (Though there is always a
trade-off between keeping consistency between versions and being able to
correct mistakes or sub-optimal decisions with later versions. A good
period of trial and testing helps here.)

>
> Here however, both null and nil are commonly used in programming
> languages for the same thing. So why not allow both? If someone uses two
> languages, one uses NULL, the other nil, if would be really convenient
> to not have to keep thinking about which one you should be using.
>
> (Although having said that, mine don't allow null! But then I am the
> only user.)
>
>>
>> And Bart, if underscore is so diffult for you (perhaps you have
>> arthritis or other challenges), I'd recommend looking at different
>> keyboards, or enabling "sticky shift keys" or similar aids supported by
>> your OS of choice.
>>
>> Certainly the use of "shift" is not relevant to language design.
>
> Simplest of all is having alphunumeric identifiers not requiring you to
> pause in the middle to deal with case or shift changes.
>

Some people like camelCase for multi-word identifiers, some prefer
underscore_separation. I can't imagine many people dislike underscore
purely because of using the shift key (though some /do/ dislike it
because they find the underscore hard to see in some circumstances).

There are a few languages that allow multi-word identifiers separated by
spaces, or allow hyphens as "letters", but those are rare, and likely to
cause confusion.

> This especially applies to keywords that you can't do anything about.
>

Certainly it makes sense to have shorter and simpler keywords, at least
for those that are commonly used. And there is no point in having extra
underscores for no purpose. I might not object to underscores as much
as you do, but I see no benefit of "null_ptr" over "nullptr".

> So I'd say it's very relevant to not having a language that is a pita to
> use.

Well, I guess the OP will collect opinions, and use that to help make
his decisions.

On 17/08/2021 22:08, David Brown wrote:
> On 17/08/2021 22:00, Bart wrote:

>> I sometimes allow a choice if I can't make up my mind about a feature or
>> a keyword. Then I can try it out and see which one feels better or looks
>> better, or which is used more often. Or I might use one form privately,
>> and another for shared code.
>
> Keeping the choice open while prototyping, developing and testing makes
> sense - that's fair enough. But once your language has solidified
> somewhat, then it's good to fix these things. (Though there is always a
> trade-off between keeping consistency between versions and being able to
> correct mistakes or sub-optimal decisions with later versions. A good
> period of trial and testing helps here.)

Another area where I like to have alternatives is basic types; the
choices on each line all refer to the same type:

byte word8 u8
word word64 u64
int int64 i64
real real64 r64 float64
int16 i16

The ones in the third column are universally understood, and I use them
for generated or shared code, but in normal source I use ones from the
first column, if they exist, or second if the width is significant or
there is no colloquial form.

The 'float64' I'd forgotten about; I guess that'll be coming out soon.

C of course famously has dozens of ways of writing some types (partly
due to them requiring multiple tokens, some optional, and which can be
in any order).

It's not surprising that so many applications define their own sets of
types. That's a worse problem than the language allowing a choice of 2 or 3.

>
> Some people like camelCase for multi-word identifiers, some prefer
> underscore_separation. I can't imagine many people dislike underscore
> purely because of using the shift key

I dislike them also because I can never remember if there is a
underscore or not.

On 18/08/2021 00:52, Bart wrote:
> On 17/08/2021 22:08, David Brown wrote:
>> On 17/08/2021 22:00, Bart wrote:
>
>>> I sometimes allow a choice if I can't make up my mind about a feature or
>>> a keyword. Then I can try it out and see which one feels better or looks
>>> better, or which is used more often. Or I might use one form privately,
>>> and another for shared code.
>>
>> Keeping the choice open while prototyping, developing and testing makes
>> sense - that's fair enough.  But once your language has solidified
>> somewhat, then it's good to fix these things.  (Though there is always a
>> trade-off between keeping consistency between versions and being able to
>> correct mistakes or sub-optimal decisions with later versions.  A good
>> period of trial and testing helps here.)
>
> Another area where I like to have alternatives is basic types; the
> choices on each line all refer to the same type:
>
> byte   word8   u8
> word   word64  u64
> int    int64   i64
> real   real64  r64 float64
>        int16   i16
>
> The ones in the third column are universally understood, and I use them
> for generated or shared code, but in normal source I use ones from the
> first column, if they exist, or second if the width is significant or
> there is no colloquial form.

When people say "universally understood", they usually mean "I like them
and don't much care about the rest of the universe". As you know, I
think these extremely short names are horrible in many ways, and I
totally disagree that they are "universally understood". With enough
context I expect people can figure out what they are, but that's another
matter entirely - and it applies equally to any naming scheme that
includes bit sizes explicitly.

You spend a significant amount of time posting on c.l.c. about how
terrible it is when people use different names for the same type,
regardless of how vital type names are to program clarity and code
flexibility. And now you are recommending multiple names for the same
type that give absolutely /no/ advantages or benefits. You also
regularly complain that in C, fundamental types like "int" and "long
int" are poorly defined and unclear, and how it is better to have
explicitly sized types (and then you won't use C's explicitly sized
types, because that would mean you couldn't whine about them). And now
you want to tell us that it's great for a language to have "word"
meaning the same thing as "word64" and "u64"!

>
> The 'float64' I'd forgotten about; I guess that'll be coming out soon.

So one of the great things about having lots of different ways to write
exactly the same thing in a language is that the language's designer,
implementer and /single/ user can't remember them all.

When planning a new language, it's good to learn about existing
languages so that you can be inspired by parts that work well, and avoid
ideas that work badly. From that second viewpoint, I think you are
helping the OP significantly.

>
> C of course famously has dozens of ways of writing some types (partly
> due to them requiring multiple tokens, some optional, and which can be
> in any order).

I would not advise copying C's system for fundamental types any more
than I would recommend copying your multiple different names. But
unless you are trying to make a programming language less user-friendly
than Forth, and less portable than assembly, a language needs a way to
name types for use in particular cases.

>
> It's not surprising that so many applications define their own sets of
> types. That's a worse problem than the language allowing a choice of 2
> or 3.

C is far from perfect here (and no one claims otherwise). What /is/
surprising is that you would suggest that the answer is to have the
language start off with multiple names so that programmers get mixed up
and inconsistent before they even start writing their own code.

>
>>
>> Some people like camelCase for multi-word identifiers, some prefer
>> underscore_separation.  I can't imagine many people dislike underscore
>> purely because of using the shift key
>
> I dislike them also because I can never remember if there is a
> underscore or not.
>

You can't even remember how your own languages work, despite having
written and implemented them and apparently written lots of code in them.

On 18/08/2021 09:40, David Brown wrote:
> On 18/08/2021 00:52, Bart wrote:
>> On 17/08/2021 22:08, David Brown wrote:
>>> On 17/08/2021 22:00, Bart wrote:
>>
>>>> I sometimes allow a choice if I can't make up my mind about a feature or
>>>> a keyword. Then I can try it out and see which one feels better or looks
>>>> better, or which is used more often. Or I might use one form privately,
>>>> and another for shared code.
>>>
>>> Keeping the choice open while prototyping, developing and testing makes
>>> sense - that's fair enough.  But once your language has solidified
>>> somewhat, then it's good to fix these things.  (Though there is always a
>>> trade-off between keeping consistency between versions and being able to
>>> correct mistakes or sub-optimal decisions with later versions.  A good
>>> period of trial and testing helps here.)
>>
>> Another area where I like to have alternatives is basic types; the
>> choices on each line all refer to the same type:
>>
>> byte   word8   u8
>> word   word64  u64
>> int    int64   i64
>> real   real64  r64 float64
>>        int16   i16
>>
>> The ones in the third column are universally understood, and I use them
>> for generated or shared code, but in normal source I use ones from the
>> first column, if they exist, or second if the width is significant or
>> there is no colloquial form.
>
> When people say "universally understood", they usually mean "I like them
> and don't much care about the rest of the universe".

No, I mean that they are used everywhere and widely understood. They're
even used in Linux kernel, see here under Typedefs:

https://www.kernel.org/doc/html/v4.10/process/coding-style.html

They are the primary types in Rust.

I believe they are used in the MSVC C compiler as suffixes for integer
literals (1234i32 and 1234ui32).

This all means they are useful as language-independent ways of refering
to such types in forums like this, because either everyone will already
know what they mean, or they can make a pretty good guess.

They are after all just contractions of C's int32_t-style family of
types, with extraneous letters (and underscores!) elided.

In my case they started off as being internal representations, then were
used in generated code, then, in order to be able to read that code back
in, they were made part of the language.

> And now
> you want to tell us that it's great for a language to have "word"
> meaning the same thing as "word64" and "u64"!

'word' is specific to my languages to mean 'unsigned integer'. The
formal, consistently named set of unsigned types go from word1 to
word128, which have the parallel naming scheme u1 to u128.

word64 also has the informal, "don't care" synonym 'word' (like 'int' is
a synonym for int64').

And 'byte' is a synonym for 'word8'.

>
>>
>> The 'float64' I'd forgotten about; I guess that'll be coming out soon.
>
> So one of the great things about having lots of different ways to write
> exactly the same thing in a language is that the language's designer,
> implementer and /single/ user can't remember them all.

I wanted something more mainstream since 'real' is not well known these
days. Probably the idea was to be be able to use it when sharing code,
so as not to have to explain when real was. But that didn't happen.

On 18/08/2021 12:59, Bart wrote:
> On 18/08/2021 09:40, David Brown wrote:
>> On 18/08/2021 00:52, Bart wrote:
>>> On 17/08/2021 22:08, David Brown wrote:
>>>> On 17/08/2021 22:00, Bart wrote:
>>>
>>>>> I sometimes allow a choice if I can't make up my mind about a
>>>>> feature or
>>>>> a keyword. Then I can try it out and see which one feels better or
>>>>> looks
>>>>> better, or which is used more often. Or I might use one form
>>>>> privately,
>>>>> and another for shared code.
>>>>
>>>> Keeping the choice open while prototyping, developing and testing makes
>>>> sense - that's fair enough.  But once your language has solidified
>>>> somewhat, then it's good to fix these things.  (Though there is
>>>> always a
>>>> trade-off between keeping consistency between versions and being
>>>> able to
>>>> correct mistakes or sub-optimal decisions with later versions.  A good
>>>> period of trial and testing helps here.)
>>>
>>> Another area where I like to have alternatives is basic types; the
>>> choices on each line all refer to the same type:
>>>
>>> byte   word8   u8
>>> word   word64  u64
>>> int    int64   i64
>>> real   real64  r64 float64
>>>         int16   i16
>>>
>>> The ones in the third column are universally understood, and I use them
>>> for generated or shared code, but in normal source I use ones from the
>>> first column, if they exist, or second if the width is significant or
>>> there is no colloquial form.
>>
>> When people say "universally understood", they usually mean "I like them
>> and don't much care about the rest of the universe".
>
> No, I mean that they are used everywhere and widely understood.

They are most certainly /not/ used everywhere. They are used in a
number of programs and a number of languages, but that is not
/everywhere/ or even remotely close to a measurable percentage of
"everywhere" in programming.

In context, if it is clear you are talking about a type, then I agree
that the short names are easily understood even if they are not names
you commonly use. But they are always less clear than something like
"int32".

> They're
> even used in Linux kernel, see here under Typedefs:
>
>   https://www.kernel.org/doc/html/v4.10/process/coding-style.html
>

No sane programmer has ever used the Linux kernel as an example of good
style for general purpose coding. It is a highly specialised program,
with a unique background (and an old background - it comes from a time
before the standardised C types like int32_t). And while Linus Torvalds
has many fine qualities, there are many of his preferred styles and
other opinions on programming and languages that are, to put it mildly,
controversial.

> They are the primary types in Rust.

IMHO that was a silly decision. I haven't used Rust for anything more
than very simple testing, but to me it seems mostly a wasted
opportunity. It has several nice ideas, but I can't see it having any
significant benefit over C++ for my kind of use. For people who can't
get their pointers right in C, and refuse to use smart pointers in C++,
then perhaps Rust's system is safer. And it has some nice things, like
pattern matching. But its various types of macros and generics are way
weaker than C++'s templates. Maybe it will gain features to compete
well with C++ - maybe C++ will gain features to compete with Rust.

>
> I believe they are used in the MSVC C compiler as suffixes for integer
> literals (1234i32 and 1234ui32).

In that use-case, I can see some advantages. (I could also see them
being the basis for printf format specifiers, rather than C's rather
ugly <inttype.h> macros. But in a new language, I'd rather see a better
system than printf anyway.)

>
> This all means they are useful as language-independent ways of refering
> to such types in forums like this, because either everyone will already
> know what they mean, or they can make a pretty good guess.
>
> They are after all just contractions of C's int32_t-style family of
> types, with extraneous letters (and underscores!) elided.
>

int32 and uint32 are simple, clear, unambiguous, easy to type, and
cannot seriously be mistaken for anything else. I personally like the
_t suffixes, but I'm quite happy to accept that others have different
opinions.

> In my case they started off as being internal representations, then were
> used in generated code, then, in order to be able to read that code back
> in, they were made part of the language.
>
>
>>  And now
>> you want to tell us that it's great for a language to have "word"
>> meaning the same thing as "word64" and "u64"!
>
> 'word' is specific to my languages to mean 'unsigned integer'. The
> formal, consistently named set of unsigned types go from word1 to
> word128, which have the parallel naming scheme u1 to u128.
>
> 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.

> And 'byte' is a synonym for 'word8'.

"byte" is fair enough - I think it's reasonable to say that the meaning
of "smallest addressable unit of memory" is outdated. But I would not
use that for an 8-bit number, I'd use it for raw memory access that does
not have any semantic information.

>
>>
>>>
>>> The 'float64' I'd forgotten about; I guess that'll be coming out soon.
>>
>> So one of the great things about having lots of different ways to write
>> exactly the same thing in a language is that the language's designer,
>> implementer and /single/ user can't remember them all.
>
> I wanted something more mainstream since 'real' is not well known these
> days. Probably the idea was to be be able to use it when sharing code,
> so as not to have to explain when real was. But that didn't happen.
>

I've nothing against "float32", "float64", etc., as type names for
floating point data. (I'd add a "_t", of course!)

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.

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.

>> 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.

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.

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.)

> 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!

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
the choice.

> 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.

On 17/08/2021 22:08, David Brown wrote:

....

> Certainly it makes sense to have shorter and simpler keywords, at least
> for those that are commonly used. And there is no point in having extra
> underscores for no purpose. I might not object to underscores as much
> as you do, but I see no benefit of "null_ptr" over "nullptr".

To be clear, I don't think I personally suggested null_ptr for the
following reasons. What I had in mind was that if there were going to be
two or more reserved pointer values then it might make sense for them to
be clearly related. And so I suggested ptr as a prefix - something like

ptr_undef
ptr_null

By contrast, if I were to use the nullptr that you mentioned then the
corresponding keywords would be

undefptr
nullptr

which is perhaps getting to be a bit hard to read. The situation would
be worse if there were many such reserved names as in

undefptr
nullptr
debugptr
signalptr
chainendptr

I know that discussion of what name to use for a reserved pointer value
is somewhat about minutiae but as I think the list shows even choices
such as this can make a difference to the readability of the program.

Not to be overlooked is the words which get reserved by the language and
so become unavailable for the programmer to use as identifier names. For
that reason, I think a better list than the above would be

ptr_undef
ptr_null
ptr_debug
ptr_signal
ptr_chainend

Although they are arguably more ugly such names would, perhaps, be
easier to read and recognise, and that would keep the reserved words as
having a common prefix. A programmer scanning the text of the program
and seeing the prefix would be able to immediately recognise it as a
special pointer value and then would only really need to notice the
specific if it was relevant to why he was looking at the code.

As I say, minor points.

....

> Well, I guess the OP will collect opinions, and use that to help make
> his decisions.
>

Yes. Opinions are always welcome.

--
James Harris

On 19/08/2021 12:13, David Brown wrote:
> On 18/08/2021 20:02, Bart wrote:

>> 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...

uint just looks like a typo to me. (On UK keyboards, u and i are
adjacent so typing 'ui' with one press is not uncommon.)

If you actually make such a typo when writing i32 or u32, then the
difference is more apparent.

> 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".

C is not the language to set examples from. A C implementation is quite
likely to define 'int32_t' on top of 'int', and 'uint32_t' on top of
'unsigned'! Somewhat circular definitions...

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.)

I used to have such schemes; my earlier languages used the following
(inspired by Fortran) on top of which the colloquial aliases were defined:

int*N for signed integers
byte*N for unsigned integers
real*N for floats

as fundamental types, where N is a byte-size. I also played with int:32
and byte:64. Then I realised I was never going to use int*7 or byte:23,
and just used hardcodes names (and saved typing those shifted "*" and ":"!)

It's a not really a problem what a language uses; people will write
whatever the language requires [except in C where people are more apt to
use typedefs for basic types].

Outside of a specific language, I might use int32 or i32 or u64. Nobody
has ever asked me what they mean (except in c.l.c.)

> 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.

OK. You don't need to use my language, or if you do, you can choose to
use 'u64' for a specific size, or create your own aliases, like I do in C.

Personally I prefer to type 'word' over 'unsigned long long int' or even
'uint64_t'.

>> 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.

Not enough for you to forget completely about it's limitations. Have a
simple loop summing filesizes, and you are likely to overflow an int32
range; certainly you have to keep it very much in mind.

This is the whole reason for the ugly size_t in C. If 'int' was 64 bits,
you could forget about size_t, off_t, time_t, clock_t, and all the rest
of that zoo.

(If you are implementing 64-bit compilers, assemblers, linkers,
interpreters and runtimes, then you /need/ a 64-bit int!)

On 18/08/2021 19:02, Bart wrote:
> On 18/08/2021 16:16, David Brown 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.

Did you really say you don't like uint because it's "unpleasant to type"?

:-o

....

> 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.

That's fine but only if you are (1) restricted to certain hardware or
(2) your language allows you to specify either the default or a range in
which the default will be required to be.

--
James Harris

On 19/08/2021 14:03, James Harris wrote:
> On 18/08/2021 19:02, Bart wrote:
>> On 18/08/2021 16:16, David Brown 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.
>
> Did you really say you don't like uint because it's "unpleasant to type"?
>
> :-o

Yeah. I just don't like it.

> ...
>
>> 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.
>
> That's fine but only if you are (1) restricted to certain hardware or
> (2) your language allows you to specify either the default or a range in
> which the default will be required to be.

I usually set the default to the target machine word size.

This works for me since, once my languages target 64 bits for example,
they're unlikely to still target 32 bits, which mainstream ones still
have to support.

I can still run on 32 bits (eg. via a C target), but it will be less
efficient as many operations will be unnecessarily 64 bits.

There could be a dedicated language version where int might be 32 or 16
bits, but I can't guarantee the same programs still working, as they may
assume the wider int type:

int worldpop = 7500 million

On 19/08/2021 14:57, Bart wrote:
> On 19/08/2021 12:13, David Brown wrote:
>> On 18/08/2021 20:02, Bart wrote:
>
>>> 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...
>
> uint just looks like a typo to me. (On UK keyboards, u and i are
> adjacent so typing 'ui' with one press is not uncommon.)

They are adjacent on most Latin alphabet keyboard layouts, I think.

>
> If you actually make such a typo when writing i32 or u32, then the
> difference is more apparent.

I find it very hard to believe that "uint32" is a common typo for
"int32" and commonly goes unnoticed, and that "u32" vs "i32" is less
significantly likely to happen or go unnoticed. But unless someone has
statistics on such errors, we'll never know for sure.

>
>> 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".
>
> C is not the language to set examples from. A C implementation is quite
> likely to define 'int32_t' on top of 'int', and 'uint32_t' on top of
> 'unsigned'! Somewhat circular definitions...

I used C as an example here, not because I think the details of its
types should be copied. C does things the way it does because they made
sense at the time, and history has passed since its conception. Despite
all your moanings and groanings, C's system was worked well for the last
50 years and continues to work well now - at least for those willing to
accept it and work with it instead of fighting it. But I would not copy
the same system for a /new/ language, nor did I suggest it.

>
>   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.)
>
> I used to have such schemes; my earlier languages used the following
> (inspired by Fortran) on top of which the colloquial aliases were defined:
>
>   int*N               for signed integers
>   byte*N              for unsigned integers
>   real*N              for floats
>
> as fundamental types, where N is a byte-size. I also played with int:32
> and byte:64. Then I realised I was never going to use int*7 or byte:23,
> and just used hardcodes names (and saved typing those shifted "*" and ":"!)
>
> It's a not really a problem what a language uses; people will write
> whatever the language requires [except in C where people are more apt to
> use typedefs for basic types].

Anybody doing serious programming in a real language is going to make
extensive use of named types - including named scaler types. There is,
of course, a need for simple little languages - not everything has to be
suitable for large-scale coding projects. But if you are going to write
large-scale software, and are interested in writing clear, maintainable
code that minimises the risk of error, then you want good typing.
Ideally there should be support for strong types here, not just aliases.

>
> Outside of a specific language, I might use int32 or i32 or u64. Nobody
> has ever asked me what they mean (except in c.l.c.)

No one in c.l.c. has asked you want they mean, to the best of my
recollection. But many have asked you why you use them, or asked you to
use standard C types when writing C instead of silly, petty
abbreviations. If you had talked about your "prgmming langage", people
would know what you meant - and question your spelling. If you
continued to insist that that's how /you/ prefer to write it, and that
it is superior to the standard spelling, people would think you are
rude, arrogant and ignorant. Unsurprisingly, you evoke similar
reactions when you post your silliness in c.l.c. (And I'd expect the
same results if I posted to comp.lang.rust with code using type "int32_t".)

>
>
>> 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.
>
> OK. You don't need to use my language, or if you do, you can choose to
> use 'u64' for a specific size, or create your own aliases, like I do in C.
>
> Personally I prefer to type 'word' over 'unsigned long long int' or even
> 'uint64_t'.
>

Well, in your language you can of course use whatever you want (as long
as you can remember what it means) - no one else is looking at your code
or using the language. But here we are not talking about /your/
personal languages - we are giving opinions and ideas to help some one
else with their language. And I assume he has ambitions that it might
be of interest to people other than himself.

>
>>> 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.
>
> Not enough for you to forget completely about it's limitations. Have a
> simple loop summing filesizes, and you are likely to overflow an int32
> range; certainly you have to keep it very much in mind.
>

Sure - if that's the kind of program you are writing.

> This is the whole reason for the ugly size_t in C. If 'int' was 64 bits,
> you could forget about size_t, off_t, time_t, clock_t, and all the rest
> of that zoo.
>

No, you could not. And I assume you are just being your usual perverse
argumentative self, rather than actually wanting to learn anything.
(You have, after all, had this stuff explained patiently and repeatedly
many times.)

> (If you are implementing 64-bit compilers, assemblers, linkers,
> interpreters and runtimes, then you /need/ a 64-bit int!)
>

Certainly a 64-bit integer type is convenient - having it as "int" is
very far from necessary.

On 19/08/2021 14:51, James Harris wrote:
> On 17/08/2021 22:08, David Brown wrote:
>
> ...
>
>> Certainly it makes sense to have shorter and simpler keywords, at least
>> for those that are commonly used.  And there is no point in having extra
>> underscores for no purpose.  I might not object to underscores as much
>> as you do, but I see no benefit of "null_ptr" over "nullptr".
>
> To be clear, I don't think I personally suggested null_ptr for the
> following reasons. What I had in mind was that if there were going to be
> two or more reserved pointer values then it might make sense for them to
> be clearly related. And so I suggested ptr as a prefix - something like
>
>   ptr_undef
>   ptr_null
>
> By contrast, if I were to use the nullptr that you mentioned then the
> corresponding keywords would be
>
>   undefptr
>   nullptr
>
> which is perhaps getting to be a bit hard to read.

I'd question the usefulness of having these as distinct names or values
in the first place (especially when balanced against the run-time cost
of manual or automatic checking of pointer validity - a comparison to 0
is cheap, a comparison to something else is not). And I'd question the
usefulness of having "ptr" as part of the name here at all. Remember,
C++ only has the name "nullptr" because it could not use "null".

You'd perhaps be better having "undefined" as a keyword and allowing it
for value types as well as pointers. Perhaps it would be a meta-value -
generating no code, but being useful for the compiler to check that the
programmer has put a real value in the variable.

> The situation would
> be worse if there were many such reserved names as in
>
>   undefptr
>   nullptr
>   debugptr
>   signalptr
>   chainendptr
>

These are definitely getting bad. Whatever you are thinking of here,
it's unlikely that making these reserved names is a good idea. A
well-designed language should aim to minimise the reserved name count,
not maximise it.

> I know that discussion of what name to use for a reserved pointer value
> is somewhat about minutiae but as I think the list shows even choices
> such as this can make a difference to the readability of the program.
>
> Not to be overlooked is the words which get reserved by the language and
> so become unavailable for the programmer to use as identifier names. For
> that reason, I think a better list than the above would be
>
>   ptr_undef
>   ptr_null
>   ptr_debug
>   ptr_signal
>   ptr_chainend
>
> Although they are arguably more ugly such names would, perhaps, be
> easier to read and recognise, and that would keep the reserved words as
> having a common prefix. A programmer scanning the text of the program
> and seeing the prefix would be able to immediately recognise it as a
> special pointer value and then would only really need to notice the
> specific if it was relevant to why he was looking at the code.
>
> As I say, minor points.
>

These are important points that are at the heart of how your language is
read and written.

Things that are used often, should be easy to read and write. Things
that are used rarely, can be hard. I don't know what you want to do
with your language, but for the sake of argument let's guess it should
be useable where C is used today. How often are null pointers used in C
code? Very often - so make it short, simple, and a keyword in your
language (such as "null"). How often are pointers to signals used?
Almost never - so it's fine if the type is pulled in from system
libraries as "system::signals::signal_pointer", and it most certainly
should /not/ be a reserved keyword.

(As a guide rule, never put anything into the language itself if it can
equally well be put in a system library.)

> ...
>
>> Well, I guess the OP will collect opinions, and use that to help make
>> his decisions.
>>
>
> Yes. Opinions are always welcome.
>
>

On 19/08/2021 15:09, David Brown wrote:
> On 19/08/2021 14:57, Bart wrote:

> I find it very hard to believe that "uint32" is a common typo for
> "int32" and commonly goes unnoticed, and that "u32" vs "i32" is less
> significantly likely to happen or go unnoticed. But unless someone has
> statistics on such errors, we'll never know for sure.

It probably takes me 50% longer to distinguish int32_t from uint32_t,
than i32 and u32. Between int32 and word32, is a bit quicker.

BTW those compact types are also used by Odin and Zig languages, not
just Rust.

> I used C as an example here, not because I think the details of its
> types should be copied. C does things the way it does because they made
> sense at the time, and history has passed since its conception. Despite
> all your moanings and groanings, C's system was worked well for the last
> 50 years and continues to work well now

No, it is still failing now. /You/ might want to adopt the [u]intN_t
types, but you still need to interact with other software that uses char
(especially char*) with its indeterminate signedness; or with int, long
and long long where long may match one of the other two but is
incompatible with neither.

And then you have those off_t types mentioned below.

>> This is the whole reason for the ugly size_t in C. If 'int' was 64 bits,
>> you could forget about size_t, off_t, time_t, clock_t, and all the rest
>> of that zoo.
>>
>
> No, you could not. And I assume you are just being your usual perverse
> argumentative self, rather than actually wanting to learn anything.

I think you can since you just don't see such types anywhere else.

At best there might be a special type such as usize, but that's likely
because many languages are still dominated by a 32-bit int type which is
too small for current data and memory and file sizes.

On 19/08/2021 15:23, David Brown wrote:
> On 19/08/2021 14:51, James Harris wrote:
>> On 17/08/2021 22:08, David Brown wrote:

....

>>   ptr_undef
>>   ptr_null
>>
>> By contrast, if I were to use the nullptr that you mentioned then the
>> corresponding keywords would be
>>
>>   undefptr
>>   nullptr
>>
>> which is perhaps getting to be a bit hard to read.
>
> I'd question the usefulness of having these as distinct names or values
> in the first place

So would I. This is just an idea, as yet.

>
> (especially when balanced against the run-time cost
> of manual or automatic checking of pointer validity - a comparison to 0
> is cheap, a comparison to something else is not).

Performance should not be a problem. It will be largely unaffected even
if there are quite a few such constants. For example, say that there
were many (more than two) values of the pointer constants starting with
these

0 = undefined
1 = null
2 = debug
etc

In a paging environment all of them would be in the lowest page. It
would be unmapped. So attempts to dereference any of them would
automatically lead to an exception - at no cost.

Where a bad pointer would have to be detected programmatically (e.g. in
the absence of paging) then instead of the nominal

cmp eax, 0
je badpointer

the generated code could have something like

cmp eax, 16
jb badpointer

Further, many of those tests could be either hoisted to be outside the
inner loop or omitted altogether where it can be proven that the
pointer's value must be in a certain range.

>
> And I'd question the
> usefulness of having "ptr" as part of the name here at all. Remember,
> C++ only has the name "nullptr" because it could not use "null".

I wondered why C++ added nullptr. From what I've found, it seems that
NULL can be automatically converted to an integer and that can cause
problems for C++'s overloading whereas nullptr cannot be so converted. I
expect there's more to it than that but it suggests that a new language
would not have to have both.

>
> You'd perhaps be better having "undefined" as a keyword and allowing it
> for value types as well as pointers. Perhaps it would be a meta-value -
> generating no code, but being useful for the compiler to check that the
> programmer has put a real value in the variable.

I am considering a course which would implement something you suggested
earlier where pointers are declared as either of these:

(pointer to T)
(pointer to T) or (null)

For an identifier declared as the former, setting the pointer to null
would be prohibited. If declared as the latter, however, then
dereferences would essentially need to be wrapped in case statements.

However, that would be part of variant typing where an object is
declared as

(T0) or (T1) or (T2) or (T3) ....

for arbitrary types Tn. Again, uses would need to be wrapped in case
statements. There would only be the one mechanism for variants but it
could be applied to pointers which could potentially be null.

But ATM that's a long way off as it would be complex to implement and I
am at a much earlier stage.

....

>> As I say, minor points.
>>
>
> These are important points that are at the heart of how your language is
> read and written.

Thanks for saying that. It's true that language (and standard library)
design is filled with a myriad of small decisions that each have a
bearing - some large, some small.

....

> (As a guide rule, never put anything into the language itself if it can
> equally well be put in a system library.)

Agreed.

--
James Harris