Re: Map iteration and modification

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:un8qgm$50cc$1@dont-email.me...
> On 2024-01-05 03:00, Randy Brukardt wrote:
...
> Thanks for posting this.
>
> I disagree with what you wrote on several points:
>
> 1. Your premise was that use = writing. To me using includes all aspects 
> of software developing and maintenance process. Writing is only a small 
> part of it.

Perhaps I didn't make it clear enough, but my premise was that many people 
making suggestions for Ada confuse "ease-of-use" with "ease-of-writing". I 
said "mischaracterized" for a reason (and I see that "mis" was missing from 
the first use, so I just added that). "Ease-of-writing" is not a thing for 
Ada, and it isn't considered while the other aspects are weighed. And as I 
said in my last message, there is a difference in that writing more can help 
understandability, but it never helps writing.

> 2. You argue for language regularity as if it were opposite to usability. 
> Again, it is pretty much obvious that a regular language is easier to use 
> in any possible sense.

But not necessarily easier to write, which was the primary topic I was 
dealing with.

> 3. Removing meaningless repetitions contributes to usability. But X := X + 
> Y is only one instance where Ada required such repetition. There are 
> others. E.g.
>
>    if X in T'Class then
>       declare
>          XT : T'Class renames T'Class (X);
>
> T'Class is repeated 3 times. A discussion point is whether a new name XT 
> could be avoided etc.

Of course, this example violates OOP dogma, and some people would argue that 
should be harder than following it. That's the same reason that Ada doesn't 
have that many implicit conversions. In this particular example, I tend to 
think the dogma is silly, but I don't off-hand see a way to avoid the 
conversion being somewhere (few implicit conversions after all).

> Introducing @ for a *single* purpose contradicts the principle of 
> regularity. I would rather have a regular syntax for most if not all such 
> instances.

@ is regular in the sense that it is allowed anywhere in an expression. If 
you tried to expand the use to other contexts, you would have to 
differentiate them, which would almost certainly require some sort of 
declaration. But doing that risks making the mechanism as wordy as what it 
replaces (which obviously defeats the purpose).

We looked at a number of ideas like that, but they didn't seem to help 
comprehension. In something like:
   LHS:(X(Y)) := LHS + 1;
(where LHS is an arbitrary identifier), if the target name is fairly long, 
it could be hard to find where the name for the target is given, and in any 
case, it adds to the name space that the programmer has to remember when 
reading the source expression. That didn't seem to add to readability as 
much as the simple @ does.

In any case, these things are trade-offs, and certainly nothing is absolute. 
But @ is certainly much more general than ":=+" would be, given that it 
works with function calls and array indexing and attributes and user-defined 
operations rather than just a single operator.

                               Randy.