On 2021-08-16 11:22, James Harris wrote:
> On 15/08/2021 19:31, Dmitry A. Kazakov wrote:
>> On 2021-08-15 19:23, James Harris wrote:
>>> On 15/08/2021 13:01, Dmitry A. Kazakov wrote:

>> Hint: apart from comparison and assignment the only pointer operation
>> would be dereferencing.
>
> I am not sure whether you would, therefore, rule out the /logic/ of
>
>   is_null(p)

Reduceable to comparison and thus irrelevant.

> I gather you don't like the proposal but what problem do you see in
> having two (or more) invalid values

There is no such thing as invalid values unless your language has broken
types.

for a pointer - especially when (1)
> they can be part of a single test and (2) an attempt to dereference
> either would be detected as an error?

These two values are semantically indistinguishable, ergo same.

An opposite case is represented by IEEE 754 floats. They also have ideal
values like null, but several of them, like NaN, +Inf etc. This is
because these are semantically different as seen in the operations:

1.0 / NaN = NaN
1.0 / +Inf = +Zero

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 16/08/2021 07:57, Dmitry A. Kazakov wrote:
> On 2021-08-15 22:23, Bart wrote:
>> On 15/08/2021 21:08, Dmitry A. Kazakov wrote:
>
>>> Nothing of above a decent language should ever have, but that is
>>> beside the point. Which is, there is no difference in behavior of
>>> pointer operations for these two proposed values. That is all.
>>
>> Which comparison operations should there be? If you include < <= >= >,
>
> Pointers are unordered.
>

You mean, like postal addresses? That would make most postmen's beats
rather erratic!

The pointers I deal with in /my/ languages are lower level than yours
and therefore are ordered:

s:="bart"

p:=&s[1]
q:=&s[4]

println =p
println =q
println =p-q
println =p<q
println =p>q
println =istrue p
println =max(p,q)

Output is:

P= Ref u8:02543040
Q= Ref u8:02543043
(P-Q)= -3
(P < Q)= 1
(P > Q)= 0
ISTRUEL(P)= 1
(P MAX Q)= Ref u8:02543043

On 16/08/2021 10:53, Dmitry A. Kazakov wrote:
> On 2021-08-16 11:22, James Harris wrote:
>> On 15/08/2021 19:31, Dmitry A. Kazakov wrote:
>>> On 2021-08-15 19:23, James Harris wrote:
>>>> On 15/08/2021 13:01, Dmitry A. Kazakov wrote:
>
>>> Hint: apart from comparison and assignment the only pointer operation
>>> would be dereferencing.
>>
>> I am not sure whether you would, therefore, rule out the /logic/ of
>>
>>    is_null(p)
>
> Reduceable to comparison and thus irrelevant.

If it's important ... what does that mean?

>
>> I gather you don't like the proposal but what problem do you see in
>> having two (or more) invalid values
>
> There is no such thing as invalid values unless your language has broken
> types.

I was talking about values which did not refer to a referent. You are a
smart guy and I guess you realise that. So I don't know why you pretend
not to.

The two or more values which did not refer to a referent would still be
legitimate and defined as part of the type so there would be no broken
type system.

>
>  for a pointer - especially when (1)
>> they can be part of a single test and (2) an attempt to dereference
>> either would be detected as an error?
>
> These two values are semantically indistinguishable, ergo same.

On the contrary, under the proposal they /would/ be distinguishable.
But, again, I am sure you realised that so I don't know why you feign a
lack of understanding.

>
> An opposite case is represented by IEEE 754 floats. They also have ideal
> values like null, but several of them, like NaN, +Inf etc. This is
> because these are semantically different as seen in the operations:
>
>   1.0 / NaN  = NaN
>   1.0 / +Inf = +Zero
>

What do you mean by IEEE 754 'null'?

--
James Harris

On 16/08/2021 11:08, Bart wrote:
> On 16/08/2021 07:57, Dmitry A. Kazakov wrote:
>> On 2021-08-15 22:23, Bart wrote:
>>> On 15/08/2021 21:08, Dmitry A. Kazakov wrote:
>>
>>>> Nothing of above a decent language should ever have, but that is
>>>> beside the point. Which is, there is no difference in behavior of
>>>> pointer operations for these two proposed values. That is all.
>>>
>>> Which comparison operations should there be? If you include < <= >= >,
>>
>> Pointers are unordered.
>>
>
> You mean, like postal addresses? That would make most postmen's beats
> rather erratic!
>
> The pointers I deal with in /my/ languages are lower level than yours
> and therefore are ordered:

OT but I guess the reason pointer values are sometimes defined as
unorderable is that they are implemented as addresses and the addresses
may come from different address spaces.

For example, if the pointers are p and q you might have p holding an
address in a local address space and q holding an address in a remote
address space. They would easily compare as unequal but neither would be
naturally before or after the other unless the two address spaces were
ordered.

Life's relatively easy in a single 64-bit address space, isn't it!

--
James Harris

On 16/08/2021 11:44, James Harris wrote:
> On 16/08/2021 11:08, Bart wrote:
>> On 16/08/2021 07:57, Dmitry A. Kazakov wrote:
>>> On 2021-08-15 22:23, Bart wrote:
>>>> On 15/08/2021 21:08, Dmitry A. Kazakov wrote:
>>>
>>>>> Nothing of above a decent language should ever have, but that is
>>>>> beside the point. Which is, there is no difference in behavior of
>>>>> pointer operations for these two proposed values. That is all.
>>>>
>>>> Which comparison operations should there be? If you include < <= >= >,
>>>
>>> Pointers are unordered.
>>>
>>
>> You mean, like postal addresses? That would make most postmen's beats
>> rather erratic!
>>
>> The pointers I deal with in /my/ languages are lower level than yours
>> and therefore are ordered:
>
> OT but I guess the reason pointer values are sometimes defined as
> unorderable is that they are implemented as addresses and the addresses
> may come from different address spaces.
>
> For example, if the pointers are p and q you might have p holding an
> address in a local address space and q holding an address in a remote
> address space. They would easily compare as unequal but neither would be
> naturally before or after the other unless the two address spaces were
> ordered.
>
> Life's relatively easy in a single 64-bit address space, isn't it!
>

A single address space doesn't necessarily make pointers ordered. In my
example, I constructed pointers into the same string. There, comparing
them made sense.

It would make less sense if they were pointers into different strings,
or I were to different target types.

While a language can check the latter, checking they refer to the same
object is harder.

(In my language, it means a pointer would need to be represented by a
reference to an object, plus an offset. Too complicated for me where
pointers in that dynamic language are a lower level but unsafe feature,
designed to just get things done, and done efficiently.)

On 2021-08-16 12:08, Bart wrote:
> On 16/08/2021 07:57, Dmitry A. Kazakov wrote:
>> On 2021-08-15 22:23, Bart wrote:
>>> On 15/08/2021 21:08, Dmitry A. Kazakov wrote:
>>
>>>> Nothing of above a decent language should ever have, but that is
>>>> beside the point. Which is, there is no difference in behavior of
>>>> pointer operations for these two proposed values. That is all.
>>>
>>> Which comparison operations should there be? If you include < <= >= >,
>>
>> Pointers are unordered.
>
> You mean, like postal addresses?

This unrelated and off topic, but yes, spatial co-ordinates are
unordered, moreover, they cannot be ordered.

A pointer can inherit order from its target type though, in an advanced
language, I must repeat that. That would be the case with a linked list
or a postman's route path stops.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 2021-08-16 12:37, James Harris wrote:
> On 16/08/2021 10:53, Dmitry A. Kazakov wrote:
>> On 2021-08-16 11:22, James Harris wrote:
>>> On 15/08/2021 19:31, Dmitry A. Kazakov wrote:
>>>> On 2021-08-15 19:23, James Harris wrote:
>>>>> On 15/08/2021 13:01, Dmitry A. Kazakov wrote:
>>
>>>> Hint: apart from comparison and assignment the only pointer
>>>> operation would be dereferencing.
>>>
>>> I am not sure whether you would, therefore, rule out the /logic/ of
>>>
>>>    is_null(p)
>>
>> Reduceable to comparison and thus irrelevant.
>
> If it's important ... what does that mean?

It means that is_null(p) == p = null

>> These two values are semantically indistinguishable, ergo same.
>
> On the contrary, under the proposal they /would/ be distinguishable.

You forgot the word "semantically." Semantics = behavior.

>> An opposite case is represented by IEEE 754 floats. They also have
>> ideal values like null, but several of them, like NaN, +Inf etc. This
>> is because these are semantically different as seen in the operations:
>>
>>    1.0 / NaN  = NaN
>>    1.0 / +Inf = +Zero
>
> What do you mean by IEEE 754 'null'?

IEEE 754 does not have 'null' as an ideal. It has NaN, +Inf, -Inf, +0,
-0. Pointers have 'null', adding another makes no sense.

Ideal is a value added to the original set of values in order to achieve
some desired properties of operations. E.g. NaN is added as a result of
0/0. null is added as a pointer for which dereferencing always fails.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 16/08/2021 12:44, James Harris wrote:
> On 16/08/2021 11:08, Bart wrote:
>> On 16/08/2021 07:57, Dmitry A. Kazakov wrote:
>>> On 2021-08-15 22:23, Bart wrote:
>>>> On 15/08/2021 21:08, Dmitry A. Kazakov wrote:
>>>
>>>>> Nothing of above a decent language should ever have, but that is
>>>>> beside the point. Which is, there is no difference in behavior of
>>>>> pointer operations for these two proposed values. That is all.
>>>>
>>>> Which comparison operations should there be? If you include < <= >= >,
>>>
>>> Pointers are unordered.
>>>
>>
>> You mean, like postal addresses? That would make most postmen's beats
>> rather erratic!
>>
>> The pointers I deal with in /my/ languages are lower level than yours
>> and therefore are ordered:
>
> OT but I guess the reason pointer values are sometimes defined as
> unorderable is that they are implemented as addresses and the addresses
> may come from different address spaces.
>

That may be one reason. Another is that different pointer "values" can
have non-obvious relationships with each other and with cpu virtual
addresses or physical memory addresses. A fine example would be 8086
segmented addresses where many different pointer "values" can refer to
the same actual memory address. Other times there can be multiple
virtual addresses pointing to the same physical address. And as always,
on odder systems you can get odder arrangements - I have worked with a
processor that uses the high bit of addresses to mean "don't cache this
access".

But generally there is a principle that when designing a programming
language, you should decide what you think actually makes sense. In
higher level programming, it doesn't make sense to treat pointers as
numerical values. There is no point in printing them, or comparing
them, any more than there is sense in multiplying them or dividing them.
It doesn't matter that they are implemented as numbers which /could/ be
compared. And if you decide that comparing pointers makes no sense,
then the language should not define that behaviour. (Ideally it should
be a syntax error of some sort.)

> For example, if the pointers are p and q you might have p holding an
> address in a local address space and q holding an address in a remote
> address space. They would easily compare as unequal but neither would be
> naturally before or after the other unless the two address spaces were
> ordered.
>
> Life's relatively easy in a single 64-bit address space, isn't it!
>
>

On 16/08/2021 13:44, Dmitry A. Kazakov wrote:
> On 2021-08-16 12:08, Bart wrote:
>> On 16/08/2021 07:57, Dmitry A. Kazakov wrote:
>>> On 2021-08-15 22:23, Bart wrote:
>>>> On 15/08/2021 21:08, Dmitry A. Kazakov wrote:
>>>
>>>>> Nothing of above a decent language should ever have, but that is
>>>>> beside the point. Which is, there is no difference in behavior of
>>>>> pointer operations for these two proposed values. That is all.
>>>>
>>>> Which comparison operations should there be? If you include < <= >= >,
>>>
>>> Pointers are unordered.
>>
>> You mean, like postal addresses?
>
> This unrelated and off topic, but yes, spatial co-ordinates are
> unordered, moreover, they cannot be ordered.

Of course they can be ordered. (a, b) < (c, d) if and only if (a < c)
or (a == c) and (b < d) is an obvious lexical ordering on two
dimensional coordinates. I suspect you are thinking about orders that
are compatible with arithmetic or magnitudes of vectors, which is a
different matter. (i.e., for complex numbers you can't have an order
that works with the concept of "bigger".)

>
> A pointer can inherit order from its target type though, in an advanced
> language, I must repeat that. That would be the case with a linked list
> or a postman's route path stops.
>

You can certainly have a concept of "position within a linked list", and
you might consider that a more general kind of pointer. That would,
however, open several new cans of worms and chicken-and-egg problems
figuring out if your linked lists are implemented using pointers, or if
your pointers are link-list-pointers. I think it's better to say that
pointers can't be compared (or at least, only very specifically related
pointers can be compared) and refer to position in a linked list as an
"index" or something like that, independent of pointers.

On 16/08/2021 10:37, James Harris wrote:
[I wrote:]
>>      Perhaps I'm missing something, but I'm not clear why you seem
>> so obsessed with "address zero". [...]
> Obsessed is putting it too strongly but zero is convenient in that if
> null is zero then any record allocated in zeroed memory would
> automatically have null pointers (if there are any in the record).

Yes, of course. But that has, or should have, absolutely
nothing to do with either the syntax or the semantics of your
language [to the extent that you intend it to be a highly portable
HLL]. If you decide that storage should be initialised, eg to
"null", /that/ is a semantic decision for you to make. But /how/
that is done is an implementation decision.

> If null were, say, 53, by contrast, any record allocated in zeroed
> memory would have to have any pointers therein initialised to 53 if
> we want to maintain the semantics that any pointers in a new record
> would begin as null.

Yes, which might well persuade an implementer that zero is
a good choice. OTOH, s/he might decide to use 53 as something very
unlikely to happen by accident and so better for diagnostics.

> That's not a major issue in itself although there may be some other
> consequence of null being something other than zero that I haven't
> yet considered.

If you follow, even at a respectable distance, Dmitri's
advice [with which I largely concur as long as you remember always
to replace his "is" with "should IMO (and as used in Ada)"], then
the only uses for "null" are (a) to assign it to pointers [eg to
indicate a pointer that cannot [legitimately] be dereferenced],
and (b) to test whether a pointer has that value [eg to mark the
end of list]. Neither of those depends on whether "null" is
all-bits-zero. In a sensible portable HLL, you shouldn't even be
able to tell whether something is all-bits-zero; even a zeroed
integer may carry around flag or padding bits -- again, a problem
for the implementer, not the language designer.

Of course, it may well be that you intend to implement as
well as design your language; but it is still important that you
separate out design from implementation. FTAOD, that is not a
claim that you should ignore implementation altogether when you
design a language feature. Rather, that you shouldn't overdo it;
implementers can legitimately have different aims as well as
different hardware.

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Heller