From mboxrd@z Thu Jan 1 00:00:00 1970 Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Map iteration and modification Date: Sat, 6 Jan 2024 01:25:46 -0600 Organization: A noiseless patient Spider Message-ID: References: Injection-Date: Sat, 6 Jan 2024 07:24:40 -0000 (UTC) Injection-Info: dont-email.me; posting-host="3be1e95d7db3e486470d4026586c5457"; logging-data="568277"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+wqbeiSOxCmpm1lzn0vNUte7ncF4dMGb4=" Cancel-Lock: sha1:cot841GykFhKfri5KcK6XZbHyGs= X-MSMail-Priority: Normal X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-Priority: 3 Xref: news.eternal-september.org comp.lang.ada:65966 List-Id: "Dmitry A. Kazakov" 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.