On 13/11/2022 16:26, Dmitry A. Kazakov wrote:
> On 2022-11-13 16:54, James Harris wrote:
>> On 07/11/2022 16:16, Dmitry A. Kazakov wrote:
>
>>> ++ means cheap keyboard with broken keys or coffee spilled over it...
>>> (:-))
>>
>> A bit like Ada's --, then. ;-)
>
> In Ada -- is a comment, not operator.

Indeed.

>
> An interesting question regarding operator's symbol is: sticking to
> ASCII or going Unicode. Let's say we wanted an increment operator (I do
> not). Why ++ from 60's? Take the increment (∆) or the upwards arrow ↑ etc.

As you know, I don't like Unicode for program source. It can be hard to
type, hard to read aloud, and hard to compare when two glyphs look the
same but have different encodings. A small set of characters such as
ASCII has none of those problems.

As for replacing ++ with something else I have tried things like

+> prefix increment
<+ postfix increment

or maybe ++> and <++.

But I don't know if programmers in general would care for them.

>
> Note that all arguments against Unicode apply to operators. If the thing
> is difficult to type then it is difficult to remember: precedence level,
> associativity, semantics. If you can hold these in your head, you could
> remember the key combination as well. If you do not, then, maybe, having
> a subprogram Increment() would be better choice?

Agreed.

--
James Harris

On 08/11/2022 08:23, Dmitry A. Kazakov wrote:
> On 2022-11-08 09:04, James Harris wrote:
>
>> I like the simplicity of the language which would result from your
>> suggestions but can't help but think they would make programming in it
>> less comfortable, like the simplicity of a hair shirt. ;)
>
> If you think programmers are dying to write stuff like *p++=*q++; you
> are wrong. Actually that train left the station. Today C++ fun is
> templates. It is monstrous instantiations over instantiations barely
> resembling program code. Modern times is a glorious combination of
> Python performance with K&R C readability! (:-))

Contrast

*p := *q
p := p + 1
q := q + 1

Perhaps

+p++ := *q++

expresses that part of the algorithm in a way which is more natural and
easier to read...?

--
James Harris

James Harris <james.harris.1@gmail.com> writes:
>As you know, I don't like Unicode for program source. It can be hard to
>type, hard to read aloud, and hard to compare when two glyphs look the
>same but have different encodings. A small set of characters such as
>ASCII has none of those problems.

But it can be cumbersome to escape all quotation characters
in a string, as in "\"\\" in C.

Imagine one would use some obscure Unicode characters as
string delimiters. For example,

ᒪ CANADIAN SYLLABICS MA
ᒧ CANADIAN SYLLABICS MO

. Programmers will surely find a way to map them to their
keyboards somehow. Then that string literal would be just
ᒧ"\ᒪ!

(One would just have to use escapes in the rare case that
one really needs to have those Canadian syllabics ma or mo
within a string literal.)

On 07/11/2022 14:23, Bart wrote:
> On 07/11/2022 11:55, James Harris wrote:

....

> For unary operators, the evaluation order is rather peculiar yet seems
> to be used in quite a few languages without anyone questioning it. So if
> `a b c d` are unary operators, then the following:
>
>    a b E c d
>
> is evaluated like this:
>
>       a (b ((E c) d))
>
> That is, first all the post-fix operators in left-to-right order, then
> all the prefix ones in right-left order. It sounds bizarre when put like
> that!

Indeed, right then left does sound unnatural, albeit that it's
relatively easy to remember. Could it be the comparative simplicity of
"right then left" is why C has postfix ++ of higher precedence than
prefix ++, even though that would be an awkward way to order such
operations?

>
>> Taking a step back and considering general expression evaluation I
>> have, so far, been defining the apparent order. And I'd like to
>> continue with that. So it should be possible to combine multiple ++
>> operators arbitrarily. For example,
>>
>>    ++E + E++
>
>
> This is well defined, as unary operators bind more tightly than binary
> ones. This is just (++E) + (++E).

Isn't it, rather,

(++E) + (E++)

?

>
> However the evaluation order for '+' is not usually well-defined, so you
> don't know which operand will be done first.
>
>>    ++E++
>
> This may not work, or not work as espected. The binding using my above
> scheme means this is equivalent to ++(E++).

Perhaps the scheme is wrong (for some definition of wrong)...?

IMO (++E)++ makes more sense.

> But the second ++ requires
> an lvalue as input, and yields an rvalue, which would be an invalid
> input to the first ++.

Better to give ++ (prefix) precedence over ++ (postfix), perhaps.

....

>> At any rate, that distinction between prefix and postfix ++ seems to
>> be recognised at the following link where it says "Prefix versions of
>> the built-in operators return references and postfix versions return
>> values."
>>
>>    https://en.cppreference.com/w/cpp/language/operator_incdec
>
> I tried to get ++E++ to work using a suitable type for E, but in my
> language it cannot work, as the first ++ still needs an lvalue; just an
> rvalue which has a pointer type won't cut it.
>
> However ++E++^ can work, where ^ is deref, and E is a pointer.
>
> I think this is because in my language, for something to be a valid
> lvalue, you need to be able to apply & address-of to it. The result of
> E++ doesn't have an address. But (E++)^ works because & and ^ cancel
> out. Or something...

As a guess, could your compiler be making an optimisation (coalescing
postincrement and dereference) in a way which contravenes the definition
of the operators?

>
>> Setting that aside aside ... and going back to the query, what should
>> be the relative precedences of the three operators? For example, how
>> should the following be evaluated?
>>
>>    ++E++^
>>    ++E^++
>>
>> Or should some ways of combining ^ with either or both of the ++
>> operators be prohibited because they make code too difficult to
>> understand?!!
>
> You have the same issues in C, but that's OK because people are so
> familiar with it. Also * deref is a prefix operator so you never have
> two distinct postfix operators, unless you write E++ --.
>
> But yes, parentheses are recommended when mixing certain prefix/postfix
> ops. I think this one is clear enough however:
>
>    -E^
>
> Deference E then negate the result. As is this: -E[i]; you wouldn't
> assume that meant (-E)[i].

Yes, of the operators you mention I have the precedence order as

array indexing
dereference
unary minus

Thus my expression parser ought to do the sensible thing in each case.
The example you give is interesting because IIRC you give all unary
prefix operators a very high precedence. ISTM that such an approach
could try to evaluate the above wrongly and that it may be better to
order precedences by what the operators consume and produce than just to
boost the precedences of prefix operators. A prime example is boolean
not. In

not a > b

the "a > b" part produces a boolean, which is a natural input to "not".
It is surely sensible to have all boolean consumers as of lower
precedence than operations which produce booleans rather than saying
that "not" has a higher precedence because it is a prefix operator. Your
choice, of course, but I know you appreciate a challenge. ;-)

--
James Harris

On 13/11/2022 19:30, Stefan Ram wrote:
> James Harris <james.harris.1@gmail.com> writes:
>> As you know, I don't like Unicode for program source. It can be hard to
>> type, hard to read aloud, and hard to compare when two glyphs look the
>> same but have different encodings. A small set of characters such as
>> ASCII has none of those problems.
>
> But it can be cumbersome to escape all quotation characters
> in a string, as in "\"\\" in C.

Rather than allowing non-ASCII in source I came up with a scheme of what
you might call 'named characters' extending the backslash idea of C to
allow names instead of single characters after the backslash. It's off
topic for this thread but it allows non-ASCII characters to be named
(such that the names consist of ASCII characters and would thus be
readable and universal).

>
> Imagine one would use some obscure Unicode characters as
> string delimiters. For example,
>
> ᒪ CANADIAN SYLLABICS MA
> ᒧ CANADIAN SYLLABICS MO
>
> . Programmers will surely find a way to map them to their
> keyboards somehow. Then that string literal would be just
> ᒧ"\ᒪ!

I cannot read that. Nor could many other programmers.

>
> (One would just have to use escapes in the rare case that
> one really needs to have those Canadian syllabics ma or mo
> within a string literal.)

--
James Harris

On 2022-11-13 20:18, James Harris wrote:
> On 08/11/2022 08:23, Dmitry A. Kazakov wrote:
>> On 2022-11-08 09:04, James Harris wrote:
>>
>>> I like the simplicity of the language which would result from your
>>> suggestions but can't help but think they would make programming in
>>> it less comfortable, like the simplicity of a hair shirt. ;)
>>
>> If you think programmers are dying to write stuff like *p++=*q++; you
>> are wrong. Actually that train left the station. Today C++ fun is
>> templates. It is monstrous instantiations over instantiations barely
>> resembling program code. Modern times is a glorious combination of
>> Python performance with K&R C readability! (:-))
>
> Contrast
>
>   *p := *q
>   p := p + 1
>   q := q + 1
>
> Perhaps
>
>   +p++ := *q++
>
> expresses that part of the algorithm in a way which is more natural and
> easier to read...?

No algorithm requires you resort to pointers. With arrays it is plain
assignment:

p := q;

which BTW could be performed in parallel or by a single instruction on a
CISC machine or with a bunch optimizations. Consider the case when the
target object requires construction and destruction. Referencing would
need to construct a new object, destruct target, construct new target,
destruct copy. In Ada the compiler is allowed to skip the intermediates
and perform bitwise copy with "adjusting" the result.

The morale: low-level overly specified stuff is not only uncomfortable
and dangerous it is greatly inefficient in large scale programming.

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

On 13/11/2022 20:19, Dmitry A. Kazakov wrote:
> On 2022-11-13 20:18, James Harris wrote:
>> On 08/11/2022 08:23, Dmitry A. Kazakov wrote:
>>> On 2022-11-08 09:04, James Harris wrote:
>>>
>>>> I like the simplicity of the language which would result from your
>>>> suggestions but can't help but think they would make programming in
>>>> it less comfortable, like the simplicity of a hair shirt. ;)
>>>
>>> If you think programmers are dying to write stuff like *p++=*q++; you
>>> are wrong. Actually that train left the station. Today C++ fun is
>>> templates. It is monstrous instantiations over instantiations barely
>>> resembling program code. Modern times is a glorious combination of
>>> Python performance with K&R C readability! (:-))
>>
>> Contrast
>>
>>    *p := *q
>>    p := p + 1
>>    q := q + 1
>>
>> Perhaps
>>
>>    +p++ := *q++
>>
>> expresses that part of the algorithm in a way which is more natural
>> and easier to read...?
>
> No algorithm requires you resort to pointers. With arrays it is plain
> assignment:
>
>    p := q;

You're assuming this is part of a loop. But perhaps other things are
happening after each *p++ = *q++: the next source or dest might be
different, or the next transfer might be of a different type and/or size.

This is what makes such lower level operations so useful. A solution in
a higher level but more limiting language might require ingenuity to get
around the strictness.

> which BTW could be performed in parallel or by a single instruction on a
> CISC machine or with a bunch optimizations.

Well, perhaps this *p++=*q++ is part of the result of such a process,
where the target happens to be C source code. Few languages higher level
than ASM are suited for that job.

But by all means continue to pour scorn on it.

On 13/11/2022 20:49, Bart wrote:
> On 13/11/2022 20:19, Dmitry A. Kazakov wrote:
>> On 2022-11-13 20:18, James Harris wrote:
>>> On 08/11/2022 08:23, Dmitry A. Kazakov wrote:
>>>> On 2022-11-08 09:04, James Harris wrote:
>>>>
>>>>> I like the simplicity of the language which would result from your
>>>>> suggestions but can't help but think they would make programming in
>>>>> it less comfortable, like the simplicity of a hair shirt. ;)
>>>>
>>>> If you think programmers are dying to write stuff like *p++=*q++;
>>>> you are wrong. Actually that train left the station. Today C++ fun
>>>> is templates. It is monstrous instantiations over instantiations
>>>> barely resembling program code. Modern times is a glorious
>>>> combination of Python performance with K&R C readability! (:-))
>>>
>>> Contrast
>>>
>>>    *p := *q
>>>    p := p + 1
>>>    q := q + 1
>>>
>>> Perhaps
>>>
>>>    +p++ := *q++
>>>
>>> expresses that part of the algorithm in a way which is more natural
>>> and easier to read...?
>>
>> No algorithm requires you resort to pointers.

This doesn't have to be about pointers, Dmitry. One could just as easily
have

a[i++] := b[j++]

>> With arrays it is plain
>> assignment:
>>
>>     p := q;
>
> You're assuming this is part of a loop. But perhaps other things are
> happening after each *p++ = *q++: the next source or dest might be
> different, or the next transfer might be of a different type and/or size.

Yes, and less than a whole array may be being copied, or part of an
array may be being copied over another part of the same array, etc.

>
> This is what makes such lower level operations so useful. A solution in
> a higher level but more limiting language might require ingenuity to get
> around the strictness.
>
>> which BTW could be performed in parallel or by a single instruction on
>> a CISC machine or with a bunch optimizations.
>
> Well, perhaps this *p++=*q++ is part of the result of such a process,
> where the target happens to be C source code. Few languages higher level
> than ASM are suited for that job.

Compilers are getting good at recognising code which can be turned into
intrinsics, though IMO we shouldn't ask too much of them.

For example, an entire loop to count the bits set in a word may be
recognised by a compiler and on an x86 target turned into a single
popcnt instruction but AISI it would be better for the language to
supply pseudofunctions for operations such as that. Why? Primarily
because they make the source code easier to read.

--
James Harris

On 2022-11-13 21:49, Bart wrote:
> On 13/11/2022 20:19, Dmitry A. Kazakov wrote:
>> On 2022-11-13 20:18, James Harris wrote:
>>> On 08/11/2022 08:23, Dmitry A. Kazakov wrote:
>>>> On 2022-11-08 09:04, James Harris wrote:
>>>>
>>>>> I like the simplicity of the language which would result from your
>>>>> suggestions but can't help but think they would make programming in
>>>>> it less comfortable, like the simplicity of a hair shirt. ;)
>>>>
>>>> If you think programmers are dying to write stuff like *p++=*q++;
>>>> you are wrong. Actually that train left the station. Today C++ fun
>>>> is templates. It is monstrous instantiations over instantiations
>>>> barely resembling program code. Modern times is a glorious
>>>> combination of Python performance with K&R C readability! (:-))
>>>
>>> Contrast
>>>
>>>    *p := *q
>>>    p := p + 1
>>>    q := q + 1
>>>
>>> Perhaps
>>>
>>>    +p++ := *q++
>>>
>>> expresses that part of the algorithm in a way which is more natural
>>> and easier to read...?
>>
>> No algorithm requires you resort to pointers. With arrays it is plain
>> assignment:
>>
>>     p := q;
>
> You're assuming this is part of a loop. But perhaps other things are
> happening after each *p++ = *q++: the next source or dest might be
> different, or the next transfer might be of a different type and/or size.
>
> This is what makes such lower level operations so useful. A solution in
> a higher level but more limiting language might require ingenuity to get
> around the strictness.
>
>> which BTW could be performed in parallel or by a single instruction on
>> a CISC machine or with a bunch optimizations.
>
> Well, perhaps this *p++=*q++ is part of the result of such a process,
> where the target happens to be C source code. Few languages higher level
> than ASM are suited for that job.
>
> But by all means continue to pour scorn on it.

Sure, the point was about algorithms. Some artificially constructed
cases do not count for programmers. This is why there is no need in such
low-level languages. If something falls out of effective and safe
techniques, the program gets redesigned.

It is called engineering. If you have to design a new type of screw for
your project, you are a bad engineer.

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

On 2022-11-13 22:06, James Harris wrote:
> On 13/11/2022 20:49, Bart wrote:
>> On 13/11/2022 20:19, Dmitry A. Kazakov wrote:
>>> On 2022-11-13 20:18, James Harris wrote:
>>>> On 08/11/2022 08:23, Dmitry A. Kazakov wrote:
>>>>> On 2022-11-08 09:04, James Harris wrote:
>>>>>
>>>>>> I like the simplicity of the language which would result from your
>>>>>> suggestions but can't help but think they would make programming
>>>>>> in it less comfortable, like the simplicity of a hair shirt. ;)
>>>>>
>>>>> If you think programmers are dying to write stuff like *p++=*q++;
>>>>> you are wrong. Actually that train left the station. Today C++ fun
>>>>> is templates. It is monstrous instantiations over instantiations
>>>>> barely resembling program code. Modern times is a glorious
>>>>> combination of Python performance with K&R C readability! (:-))
>>>>
>>>> Contrast
>>>>
>>>>    *p := *q
>>>>    p := p + 1
>>>>    q := q + 1
>>>>
>>>> Perhaps
>>>>
>>>>    +p++ := *q++
>>>>
>>>> expresses that part of the algorithm in a way which is more natural
>>>> and easier to read...?
>>>
>>> No algorithm requires you resort to pointers.
>
> This doesn't have to be about pointers, Dmitry. One could just as easily
> have
>
>   a[i++] := b[j++]

Same question. What for?

Why not a[i expexp(Pi) sqrtsqrt] := b[j!!]. Where are post square root,
post exponentiation, post factorial when the humankind need them so bad?

You remind be a salesman selling the toaster equipped with a toilet
brush. Know what? I do not need this combination...

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

On 13/11/2022 21:29, Dmitry A. Kazakov wrote:
> On 2022-11-13 22:06, James Harris wrote:
>> On 13/11/2022 20:49, Bart wrote:
>>> On 13/11/2022 20:19, Dmitry A. Kazakov wrote:
>>>> On 2022-11-13 20:18, James Harris wrote:
>>>>> On 08/11/2022 08:23, Dmitry A. Kazakov wrote:
>>>>>> On 2022-11-08 09:04, James Harris wrote:
>>>>>>
>>>>>>> I like the simplicity of the language which would result from
>>>>>>> your suggestions but can't help but think they would make
>>>>>>> programming in it less comfortable, like the simplicity of a hair
>>>>>>> shirt. ;)
>>>>>>
>>>>>> If you think programmers are dying to write stuff like *p++=*q++;
>>>>>> you are wrong. Actually that train left the station. Today C++ fun
>>>>>> is templates. It is monstrous instantiations over instantiations
>>>>>> barely resembling program code. Modern times is a glorious
>>>>>> combination of Python performance with K&R C readability! (:-))
>>>>>
>>>>> Contrast
>>>>>
>>>>>    *p := *q
>>>>>    p := p + 1
>>>>>    q := q + 1
>>>>>
>>>>> Perhaps
>>>>>
>>>>>    +p++ := *q++
>>>>>
>>>>> expresses that part of the algorithm in a way which is more natural
>>>>> and easier to read...?
>>>>
>>>> No algorithm requires you resort to pointers.
>>
>> This doesn't have to be about pointers, Dmitry. One could just as
>> easily have
>>
>>    a[i++] := b[j++]
>
> Same question. What for?

What do you mean, "What for?"?

>
> Why not a[i expexp(Pi) sqrtsqrt] := b[j!!]. Where are post square root,
> post exponentiation, post factorial when the humankind need them so bad?

I cannot tell what point you are trying to make.

>
> You remind be a salesman selling the toaster equipped with a toilet
> brush. Know what? I do not need this combination...

I think you only need the toilet brush.

--
James Harris

On 13/11/2022 21:29, Dmitry A. Kazakov wrote:
> On 2022-11-13 22:06, James Harris wrote:
>> On 13/11/2022 20:49, Bart wrote:
>>> On 13/11/2022 20:19, Dmitry A. Kazakov wrote:
>>>> On 2022-11-13 20:18, James Harris wrote:
>>>>> On 08/11/2022 08:23, Dmitry A. Kazakov wrote:
>>>>>> On 2022-11-08 09:04, James Harris wrote:
>>>>>>
>>>>>>> I like the simplicity of the language which would result from
>>>>>>> your suggestions but can't help but think they would make
>>>>>>> programming in it less comfortable, like the simplicity of a hair
>>>>>>> shirt. ;)
>>>>>>
>>>>>> If you think programmers are dying to write stuff like *p++=*q++;
>>>>>> you are wrong. Actually that train left the station. Today C++ fun
>>>>>> is templates. It is monstrous instantiations over instantiations
>>>>>> barely resembling program code. Modern times is a glorious
>>>>>> combination of Python performance with K&R C readability! (:-))
>>>>>
>>>>> Contrast
>>>>>
>>>>>    *p := *q
>>>>>    p := p + 1
>>>>>    q := q + 1
>>>>>
>>>>> Perhaps
>>>>>
>>>>>    +p++ := *q++
>>>>>
>>>>> expresses that part of the algorithm in a way which is more natural
>>>>> and easier to read...?
>>>>
>>>> No algorithm requires you resort to pointers.
>>
>> This doesn't have to be about pointers, Dmitry. One could just as
>> easily have
>>
>>    a[i++] := b[j++]
>
> Same question. What for?
>
> Why not a[i expexp(Pi) sqrtsqrt] := b[j!!]. Where are post square root,
> post exponentiation, post factorial when the humankind need them so bad?
>
> You remind be a salesman selling the toaster equipped with a toilet
> brush. Know what? I do not need this combination...

But I do!

My largest program uses ++ nearly 1000 times (all varieties).

It would use expexp, sqrtsqrt or !! exactly zero times each. So it would
be very poor language design, and pointless.

There is also no prior art; noone would have a clue what it meant.
Neither do I; I think your sqrtsqrt means:

(t:=x; x:=sqrt(x); t)

But this is easy enough to implement within usercode; it doesn't need a
dedicated language feature, as it's not something that a decent
percentage of a language's community would commonly use.

On 2022-11-13 23:10, James Harris wrote:
> On 13/11/2022 21:29, Dmitry A. Kazakov wrote:
>> On 2022-11-13 22:06, James Harris wrote:
>>> On 13/11/2022 20:49, Bart wrote:
>>>> On 13/11/2022 20:19, Dmitry A. Kazakov wrote:
>>>>> On 2022-11-13 20:18, James Harris wrote:
>>>>>> On 08/11/2022 08:23, Dmitry A. Kazakov wrote:
>>>>>>> On 2022-11-08 09:04, James Harris wrote:
>>>>>>>
>>>>>>>> I like the simplicity of the language which would result from
>>>>>>>> your suggestions but can't help but think they would make
>>>>>>>> programming in it less comfortable, like the simplicity of a
>>>>>>>> hair shirt. ;)
>>>>>>>
>>>>>>> If you think programmers are dying to write stuff like *p++=*q++;
>>>>>>> you are wrong. Actually that train left the station. Today C++
>>>>>>> fun is templates. It is monstrous instantiations over
>>>>>>> instantiations barely resembling program code. Modern times is a
>>>>>>> glorious combination of Python performance with K&R C
>>>>>>> readability! (:-))
>>>>>>
>>>>>> Contrast
>>>>>>
>>>>>>    *p := *q
>>>>>>    p := p + 1
>>>>>>    q := q + 1
>>>>>>
>>>>>> Perhaps
>>>>>>
>>>>>>    +p++ := *q++
>>>>>>
>>>>>> expresses that part of the algorithm in a way which is more
>>>>>> natural and easier to read...?
>>>>>
>>>>> No algorithm requires you resort to pointers.
>>>
>>> This doesn't have to be about pointers, Dmitry. One could just as
>>> easily have
>>>
>>>    a[i++] := b[j++]
>>
>> Same question. What for?
>
> What do you mean, "What for?"?

Show me the algorithm.
>> Why not a[i expexp(Pi) sqrtsqrt] := b[j!!]. Where are post square
>> root, post exponentiation, post factorial when the humankind need them
>> so bad?
>
> I cannot tell what point you are trying to make.

There exist an infinite number of combinations that could be operators.
E.g. divide by two and reboot the computer.

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

On 13/11/2022 18:11, James Harris wrote:
> On 08/11/2022 16:29, David Brown wrote:
>> On 08/11/2022 14:24, James Harris wrote:
>
> ...
>
>> You can't stop everything - those evil programmers have better
>> imaginations than any well-meaning language designer.  But you can
>> try.   Aim to make it harder to write convoluted code, and easier to
>> write clearer code.  And try to make the clearer code more efficient,
>> to reduce the temptation to write evil code.
>
> I agree
>
> ...
>
>>> In a similar way, programming can be hard when other programmers
>>> write constructs we don't like. I agree that it's best for a language
>>> to help programmers write readable and comprehensible programs - and
>>> even to make them the easiest to write, if possible - but the very
>>> flexibility which may allow them to do so may also give then the
>>> freedom to write code we don't care for. I don't think one can
>>> legislate against that.
>>>
>>
>> I'm not sure it is the same - after all, if some one exercises their
>> rights to speak gibberish, or to give long, convoluted and
>> incomprehensible speaches, the listener has the right to go away,
>> ignore them, or fall asleep.  It's harder for a compiler to do that!
>
> I'm not worried about the compiler. As long as it can make sense of a
> piece of code then it can compile it. It's the human I am concerned
> about, especially the poor old maintenance programmer!
>

You /say/ that, but you don't appear to believe it or be interested in
making it happen.

On the one side, you claim you want a clear language that is
understandable for programmers and maintenance. On the other side, you
want to decide what "++E++" should mean, with random "^" characters
thrown in for good measure.

These two statements go together as well as Dmitry's toaster and toilet
brush. It doesn't matter how precisely you define how the combination
can be used and what it does, it is still not a good or useful thing.

On 14/11/2022 07:52, Dmitry A. Kazakov wrote:
> On 2022-11-13 23:10, James Harris wrote:
>> On 13/11/2022 21:29, Dmitry A. Kazakov wrote:
>>> On 2022-11-13 22:06, James Harris wrote:
>>>> On 13/11/2022 20:49, Bart wrote:
>>>>> On 13/11/2022 20:19, Dmitry A. Kazakov wrote:
>>>>>> On 2022-11-13 20:18, James Harris wrote:

....

>>>>>>> Contrast
>>>>>>>
>>>>>>>    *p := *q
>>>>>>>    p := p + 1
>>>>>>>    q := q + 1
>>>>>>>
>>>>>>> Perhaps
>>>>>>>
>>>>>>>    +p++ := *q++
>>>>>>>
>>>>>>> expresses that part of the algorithm in a way which is more
>>>>>>> natural and easier to read...?
>>>>>>
>>>>>> No algorithm requires you resort to pointers.
>>>>
>>>> This doesn't have to be about pointers, Dmitry. One could just as
>>>> easily have
>>>>
>>>>    a[i++] := b[j++]
>>>
>>> Same question. What for?
>>
>> What do you mean, "What for?"?
>
> Show me the algorithm.

There's no particular algorithm; the construct is a potential component
of many algorithms. It's as though someone points out a brick and
someone else says "what does it mean?" or "show me the house that would
be built from it before I can judge whether a brick is a good idea or
not". It's a potential component, nothing more.

>>> Why not a[i expexp(Pi) sqrtsqrt] := b[j!!]. Where are post square
>>> root, post exponentiation, post factorial when the humankind need
>>> them so bad?
>>
>> I cannot tell what point you are trying to make.
>
> There exist an infinite number of combinations that could be operators.
> E.g. divide by two and reboot the computer.

OK. ATM I have a generous **but limited** number of operators. For
anything else the programmer would have to call a function. For example,
I mentioned here recently that some compilers are extensive enough that
they can recognise a loop which counts the number of bits set in a word.
I would not have that as an operator but as a function (or
pseudofunction). It might be invoked on c as

x := a + b + bitcount(c) + d

Again, IMO it's important for the language to provide such
pseudofunctions so that a programmer's code can be made clearer,
simpler, and more readable.

--
James Harris

James Harris <james.harris.1@gmail.com> writes:
>Rather than allowing non-ASCII in source I came up with a scheme of what
>you might call 'named characters' extending the backslash idea of C to
>allow names instead of single characters after the backslash. It's off
>topic for this thread but it allows non-ASCII characters to be named
>(such that the names consist of ASCII characters and would thus be
>readable and universal).

Here's an example of a Python program.

print( "\N{REVERSE SOLIDUS}\N{QUOTATION MARK}" )

It prints:

\"

. But in Python one could also write

print( r'\"' )

to get the same output.

On 2022-11-14 11:16, James Harris wrote:
> On 14/11/2022 07:52, Dmitry A. Kazakov wrote:
>> On 2022-11-13 23:10, James Harris wrote:
>>> On 13/11/2022 21:29, Dmitry A. Kazakov wrote:
>>>> On 2022-11-13 22:06, James Harris wrote:
>>>>> On 13/11/2022 20:49, Bart wrote:
>>>>>> On 13/11/2022 20:19, Dmitry A. Kazakov wrote:
>>>>>>> On 2022-11-13 20:18, James Harris wrote:
>
> ...
>
>>>>>>>> Contrast
>>>>>>>>
>>>>>>>>    *p := *q
>>>>>>>>    p := p + 1
>>>>>>>>    q := q + 1
>>>>>>>>
>>>>>>>> Perhaps
>>>>>>>>
>>>>>>>>    +p++ := *q++
>>>>>>>>
>>>>>>>> expresses that part of the algorithm in a way which is more
>>>>>>>> natural and easier to read...?
>>>>>>>
>>>>>>> No algorithm requires you resort to pointers.
>>>>>
>>>>> This doesn't have to be about pointers, Dmitry. One could just as
>>>>> easily have
>>>>>
>>>>>    a[i++] := b[j++]
>>>>
>>>> Same question. What for?
>>>
>>> What do you mean, "What for?"?
>>
>> Show me the algorithm.
>
> There's no particular algorithm; the construct is a potential component
> of many algorithms.

Show me one that is not array assignment.

> It's as though someone points out a brick and
> someone else says "what does it mean?"

No, it is like building up a brick factory in your back garden for the
purpose of cracking walnuts...

>>>> Why not a[i expexp(Pi) sqrtsqrt] := b[j!!]. Where are post square
>>>> root, post exponentiation, post factorial when the humankind need
>>>> them so bad?
>>>
>>> I cannot tell what point you are trying to make.
>>
>> There exist an infinite number of combinations that could be
>> operators. E.g. divide by two and reboot the computer.
>
> OK. ATM I have a generous **but limited** number of operators.

Limited by which criteria?

> Again, IMO it's important for the language to provide such
> pseudofunctions so that a programmer's code can be made clearer,
> simpler, and more readable.

Like this one?

++p+++

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

On 14/11/2022 09:26, David Brown wrote:
> On 13/11/2022 18:11, James Harris wrote:
>> On 08/11/2022 16:29, David Brown wrote:
>>
>> ...
>>
>>> You can't stop everything - those evil programmers have better
>>> imaginations than any well-meaning language designer.  But you can
>>> try.   Aim to make it harder to write convoluted code, and easier to
>>> write clearer code.  And try to make the clearer code more efficient,
>>> to reduce the temptation to write evil code.
>>
>> I agree

....

>> I'm not worried about the compiler. As long as it can make sense of a
>> piece of code then it can compile it. It's the human I am concerned
>> about, especially the poor old maintenance programmer!
>>
>
> You /say/ that, but you don't appear to believe it or be interested in
> making it happen.

That comment surprises me a little. /The main point/ of this, AISI, is
to make the job of the programmer simpler and to help him write code
which is more readable. You said yourself that (paraphrasing) when
there's a choice between clear and convoluted code it's important for a
language to make the clearer code the easier one to write.

>
> On the one side, you claim you want a clear language that is
> understandable for programmers and maintenance.

Yes.

> On the other side, you
> want to decide what "++E++" should mean, with random "^" characters
> thrown in for good measure.

Not quite. As language designer I have to decide what facilities will be
provided but I do not have absolute control over what a programmer may
do with the facilities. Nor would a programmer want to work with a
language which implemented unnecessary rules or rules which he may see
as arbitrary.

The expression you mention is just one of a myriad of what you might
consider to be potential nasties. If I am going to prohibit that one
then what about all the others?

>
> These two statements go together as well as Dmitry's toaster and toilet
> brush.  It doesn't matter how precisely you define how the combination
> can be used and what it does, it is still not a good or useful thing.

OK, let's take the combination you mentioned:

++E++

I wonder why you see a problem with it. As I see it, it increments E
before evaluation and then increments E after evaluation. What is so
complex about that? It does exactly what it says on the tin, and in the
order that it says it. Remember that unlike C I define the apparent
order of evaluation so the expression is perfectly well formed.

--
James Harris

On 14/11/2022 09:26, David Brown wrote:
> On 13/11/2022 18:11, James Harris wrote:
>> On 08/11/2022 16:29, David Brown wrote:

>> I'm not worried about the compiler. As long as it can make sense of a
>> piece of code then it can compile it. It's the human I am concerned
>> about, especially the poor old maintenance programmer!
>>
>
> You /say/ that, but you don't appear to believe it or be interested in
> making it happen.
>
> On the one side, you claim you want a clear language that is
> understandable for programmers and maintenance.  On the other side, you
> want to decide what "++E++" should mean, with random "^" characters
> thrown in for good measure.

In-place, value-returning increment ops written as ++ and -- are common
in languages.

So are pointer-dereference operators in lower-level languages, whether
written as * or ^.

Once you have those two possibilities in a language, why shouldn't you
define what combinations of those operators might mean?

(I just differ from James in thinking that successive *value-returning**
++ or -- operators, whether prefix or postfix, are not meaningful. I'd
also think it would be bad form to chain them, but it is not practical
to be ban at the syntax level.

However, I have sometimes banned even `a+b` in some contexts, when the
resulting value is unused.)

Is your point that you shouldn't have either of those operators? ++ and
-- can be replaced at some inconvenience. But getting rid of dereference
is harder; if P is a pointer:

print P

will this display the value of the pointer, or the value of its target?
If only there was a way to specify that precisely!

Note that when p and q are byte pointers, then *p++ = *q++ (or p++^ :=
q++^) corresponds to the one-byte Z80 LDI instruction.

So it's something so meaningless that that tiny 8-bit processor decided
to give it its own instruction.

On 14/11/2022 10:32, Dmitry A. Kazakov wrote:
> On 2022-11-14 11:16, James Harris wrote:

>>>>>>    a[i++] := b[j++]
>>>>>
>>>>> Same question. What for?
>>>>
>>>> What do you mean, "What for?"?
>>>
>>> Show me the algorithm.
>>
>> There's no particular algorithm; the construct is a potential
>> component of many algorithms.
>
> Show me one that is not array assignment.

What exactly is your objection: that there shouldn't be an increment
operator at all?

Then it's end of discussion. But if you allow a value-returning
increment operator, then someone could use it in multiple places in the
same expresion, together with other operators, and the language has to
be able to deal with it.

Note that any language that has reference parameters would allow this:

a[postincr(i)] := b[postincr(j)]

Or is that something else you're not keen on?

On 14/11/2022 10:32, Dmitry A. Kazakov wrote:
> On 2022-11-14 11:16, James Harris wrote:
>> On 14/11/2022 07:52, Dmitry A. Kazakov wrote:
>>> On 2022-11-13 23:10, James Harris wrote:
>>>> On 13/11/2022 21:29, Dmitry A. Kazakov wrote:
>>>>> On 2022-11-13 22:06, James Harris wrote:
>>>>>> On 13/11/2022 20:49, Bart wrote:
>>>>>>> On 13/11/2022 20:19, Dmitry A. Kazakov wrote:
>>>>>>>> On 2022-11-13 20:18, James Harris wrote:
>>
>> ...
>>
>>>>>>>>> Contrast
>>>>>>>>>
>>>>>>>>>    *p := *q
>>>>>>>>>    p := p + 1
>>>>>>>>>    q := q + 1
>>>>>>>>>
>>>>>>>>> Perhaps
>>>>>>>>>
>>>>>>>>>    +p++ := *q++
>>>>>>>>>
>>>>>>>>> expresses that part of the algorithm in a way which is more
>>>>>>>>> natural and easier to read...?
>>>>>>>>
>>>>>>>> No algorithm requires you resort to pointers.
>>>>>>
>>>>>> This doesn't have to be about pointers, Dmitry. One could just as
>>>>>> easily have
>>>>>>
>>>>>>    a[i++] := b[j++]
>>>>>
>>>>> Same question. What for?
>>>>
>>>> What do you mean, "What for?"?
>>>
>>> Show me the algorithm.
>>
>> There's no particular algorithm; the construct is a potential
>> component of many algorithms.
>
> Show me one that is not array assignment.

if is_name_first(b[j])
a[i++] = b[j++]
rep while is_name_follow(b[j])
a[i++] = b[j++]
end rep
a[i] = 0
return TOK_NAME
end if

Now, what don't you like about the ++ operators in that? How would you
prefer to write it?

>
>> It's as though someone points out a brick and someone else says "what
>> does it mean?"
>
> No, it is like building up a brick factory in your back garden for the
> purpose of cracking walnuts...

Says the man who likes Ada! ;-)

>>>>> Why not a[i expexp(Pi) sqrtsqrt] := b[j!!]. Where are post square
>>>>> root, post exponentiation, post factorial when the humankind need
>>>>> them so bad?
>>>>
>>>> I cannot tell what point you are trying to make.
>>>
>>> There exist an infinite number of combinations that could be
>>> operators. E.g. divide by two and reboot the computer.
>>
>> OK. ATM I have a generous **but limited** number of operators.
>
> Limited by which criteria?

The set of operators is limited to what's reasonably necessary such as
the usual stuff: function calls, array references, field selection,
bitwise operations, arithmetic, comparison, boolean and assignment. Most
are present in C; only a few are not such as bitwise combinations (e.g.
nand and nor) and these two: concatenate and boolean (aka logical) xor.
What's so bad about that?

>
>> Again, IMO it's important for the language to provide such
>> pseudofunctions so that a programmer's code can be made clearer,
>> simpler, and more readable.
>
> Like this one?
>
>    ++p+++

I don't have a +++ operator so I am not sure what that is supposed to
mean. It's no valid in my language.

--
James Harris

On 13/11/2022 16:55, James Harris wrote:
> On 10/11/2022 10:42, Bart wrote:

>> It's clear that ++(A+B) can't work unless you change what ++ means
>> (eg. ++A now means (A+1) because whatever ++ modifies is not accessible).
>
> It's similar if A were a struct. You could have
>
>   A.F
>
> but you could not have
>
>   (A + 4).F
>
> The LHS of the . operation, in this case, has to be an lvalue.

That's not right. C allows functions to return structs; they are not
lvalues, but you can apply ".":

typedef struct{int x,y;}Point;

Point F(void) {
Point p;
return p;
}

int main(void)
{
Point p;
int a;

// F()=p; // Not valid: not an lvalue
a=F().x; // Valid
}

On 14/11/2022 10:44, James Harris wrote:
> On 14/11/2022 09:26, David Brown wrote:
>> On 13/11/2022 18:11, James Harris wrote:
>>> On 08/11/2022 16:29, David Brown wrote:
>>>
>>> ...
>>>
>>>> You can't stop everything - those evil programmers have better
>>>> imaginations than any well-meaning language designer.  But you can
>>>> try.   Aim to make it harder to write convoluted code, and easier to
>>>> write clearer code.  And try to make the clearer code more
>>>> efficient, to reduce the temptation to write evil code.
>>>
>>> I agree
>
> ...
>
>>> I'm not worried about the compiler. As long as it can make sense of a
>>> piece of code then it can compile it. It's the human I am concerned
>>> about, especially the poor old maintenance programmer!
>>>
>>
>> You /say/ that, but you don't appear to believe it or be interested in
>> making it happen.
>
> That comment surprises me a little. /The main point/ of this, AISI, is
> to make the job of the programmer simpler and to help him write code
> which is more readable. You said yourself that (paraphrasing) when
> there's a choice between clear and convoluted code it's important for a
> language to make the clearer code the easier one to write.
>
>>
>> On the one side, you claim you want a clear language that is
>> understandable for programmers and maintenance.
>
> Yes.
>
>
>> On the other side, you want to decide what "++E++" should mean, with
>> random "^" characters thrown in for good measure.
>
> Not quite. As language designer I have to decide what facilities will be
> provided but I do not have absolute control over what a programmer may
> do with the facilities. Nor would a programmer want to work with a
> language which implemented unnecessary rules or rules which he may see
> as arbitrary.
>
> The expression you mention is just one of a myriad of what you might
> consider to be potential nasties. If I am going to prohibit that one
> then what about all the others?
>
>
>>
>> These two statements go together as well as Dmitry's toaster and
>> toilet brush.  It doesn't matter how precisely you define how the
>> combination can be used and what it does, it is still not a good or
>> useful thing.
>
> OK, let's take the combination you mentioned:
>
>   ++E++
>
> I wonder why you see a problem with it. As I see it, it increments E
> before evaluation and then increments E after evaluation. What is so
> complex about that? It does exactly what it says on the tin, and in the
> order that it says it. Remember that unlike C I define the apparent
> order of evaluation so the expression is perfectly well formed.

But does this have the same priorities as:

op1 E op2

(where op2 is commonly done first) or does it have special rules, so
that in:

--E++

the -- is done first? If it's different, then what is the ordering when
mixed with other unary ops?

You explained somewhere the circumstances where you think this is
meaningful, but I can't remember what the rules are and I can't find the
exact post.

This is the problem. You shouldn't need to stop and think. I make the
rules simple by stipulating that value-returning ++ and -- only ever
return rvalues.

Because if they ever start to return lvalues, then this becomes possible:

++E := 0
E++ := 0

(Whichever one is legal in your scheme.) So I think there is little
useful expressivity to be gained.

On 2022-11-14 12:00, Bart wrote:
> On 14/11/2022 10:32, Dmitry A. Kazakov wrote:
>> On 2022-11-14 11:16, James Harris wrote:
>
>>>>>>>    a[i++] := b[j++]
>>>>>>
>>>>>> Same question. What for?
>>>>>
>>>>> What do you mean, "What for?"?
>>>>
>>>> Show me the algorithm.
>>>
>>> There's no particular algorithm; the construct is a potential
>>> component of many algorithms.
>>
>> Show me one that is not array assignment.
>
> What exactly is your objection: that there shouldn't be an increment
> operator at all?

There is no objection because, so far, there was no argument.
> Note that any language that has reference parameters would allow this:
>
>    a[postincr(i)] := b[postincr(j)]
>
> Or is that something else you're not keen on?

That language shall not have by-value or by-reference objects unless
explicitly contracted by the programmer. Forcing by-reference on scalars
is the best way to turn a modern processor into an i368.

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

On 2022-11-14 12:03, James Harris wrote:
> On 14/11/2022 10:32, Dmitry A. Kazakov wrote:
>> On 2022-11-14 11:16, James Harris wrote:
>>> On 14/11/2022 07:52, Dmitry A. Kazakov wrote:
>>>> On 2022-11-13 23:10, James Harris wrote:
>>>>> On 13/11/2022 21:29, Dmitry A. Kazakov wrote:
>>>>>> On 2022-11-13 22:06, James Harris wrote:
>>>>>>> On 13/11/2022 20:49, Bart wrote:
>>>>>>>> On 13/11/2022 20:19, Dmitry A. Kazakov wrote:
>>>>>>>>> On 2022-11-13 20:18, James Harris wrote:
>>>
>>> ...
>>>
>>>>>>>>>> Contrast
>>>>>>>>>>
>>>>>>>>>>    *p := *q
>>>>>>>>>>    p := p + 1
>>>>>>>>>>    q := q + 1
>>>>>>>>>>
>>>>>>>>>> Perhaps
>>>>>>>>>>
>>>>>>>>>>    +p++ := *q++
>>>>>>>>>>
>>>>>>>>>> expresses that part of the algorithm in a way which is more
>>>>>>>>>> natural and easier to read...?
>>>>>>>>>
>>>>>>>>> No algorithm requires you resort to pointers.
>>>>>>>
>>>>>>> This doesn't have to be about pointers, Dmitry. One could just as
>>>>>>> easily have
>>>>>>>
>>>>>>>    a[i++] := b[j++]
>>>>>>
>>>>>> Same question. What for?
>>>>>
>>>>> What do you mean, "What for?"?
>>>>
>>>> Show me the algorithm.
>>>
>>> There's no particular algorithm; the construct is a potential
>>> component of many algorithms.
>>
>> Show me one that is not array assignment.
>
>   if is_name_first(b[j])
>     a[i++] = b[j++]
>     rep while is_name_follow(b[j])
>       a[i++] = b[j++]
>     end rep
>     a[i] = 0
>     return TOK_NAME
>   end if
>
> Now, what don't you like about the ++ operators in that? How would you
> prefer to write it?

From parser production code:

procedure Get_Identifier
( Code : in out Source'Class;
Line : String;
Pointer : Integer;
Argument : out Tokens.Argument_Token
) is
Index : Integer := Pointer + 1;
Malformed : Boolean := False;
Underline : Boolean := False;
Symbol : Character;
begin
while Index <= Line'Last loop
Symbol := Line (Index);
if Is_Alphanumeric (Symbol) then
Underline := False;
elsif '_' = Symbol then
Malformed := Malformed or Underline;
Underline := True;
else
exit;
end if;
Index := Index + 1;
end loop;
Malformed := Malformed or Underline;
Set_Pointer (Code, Index);
Argument.Location := Link (Code);
Argument.Value := new Identifier (Index - Pointer);
declare
This : Identifier renames Identifier (Argument.Value.all);
begin
This.Location := Argument.Location;
This.Malformed := Malformed;
This.Value := Line (Pointer..Index - 1);
end;
end Get_Identifier;

>>> It's as though someone points out a brick and someone else says "what
>>> does it mean?"
>>
>> No, it is like building up a brick factory in your back garden for the
>> purpose of cracking walnuts...
>
> Says the man who likes Ada! ;-)
>
>>>>>> Why not a[i expexp(Pi) sqrtsqrt] := b[j!!]. Where are post square
>>>>>> root, post exponentiation, post factorial when the humankind need
>>>>>> them so bad?
>>>>>
>>>>> I cannot tell what point you are trying to make.
>>>>
>>>> There exist an infinite number of combinations that could be
>>>> operators. E.g. divide by two and reboot the computer.
>>>
>>> OK. ATM I have a generous **but limited** number of operators.
>>
>> Limited by which criteria?
>
> The set of operators is limited to what's reasonably necessary such as
> the usual stuff: function calls, array references, field selection,
> bitwise operations, arithmetic, comparison, boolean and assignment. Most
> are present in C; only a few are not such as bitwise combinations (e.g.
> nand and nor) and these two: concatenate and boolean (aka logical) xor.
> What's so bad about that?

You came to a conclusion without putting any objective criteria upfront.

>>> Again, IMO it's important for the language to provide such
>>> pseudofunctions so that a programmer's code can be made clearer,
>>> simpler, and more readable.
>>
>> Like this one?
>>
>>     ++p+++
>
> I don't have a +++ operator so I am not sure what that is supposed to
> mean. It's no valid in my language.

It could a part of even simpler and brilliantly readable:

++p+++q+++r

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