Re: Map iteration and modification

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2024-01-05 03:00, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:un64o3$3krch$1@dont-email.me...
> ...
>>> Exactly. These operations, especially slicing, have a huge impact on the
>>> cost of parameter passing for arrays (whether or not they are used). And
>>> that's a pretty fundamental operation.
>>
>> It is not slicing it is dynamically constrained arrays which are required
>> anyway. A general problem of language design is how to treat statically
>> known constraints effectively.
> 
> No, it's the combination of slicing and passing arrays with unknown (at
> compile-time) constraints that causes problems.

As well as passing non-null pointers, discriminated objects, class-wide 
objects...

> And it only causes problems
> if you want to separate the array interface and the array implementation
> (which we both want to do). In such a case, you are passing arrays with
> unknown constraints and implementation. Assignable slices don't work with
> that, as they require a contiguous implementation of elements.

Only if the base type implementation is contiguous. A slice of a 
non-contiguous container is non-contiguous. If you can deal with the 
first you can do with the second.

The crucial point is removing static constraints from the instances 
which Ada does on some occasions and not on others, especially for the 
user-defined types.

> Inferfacing is using the array implementation, not the array interface. Of
> course it works great, as you note Ada commingles those in a way that makes
> them inseparable. To separate them, you are going to have to lose something.

Sure, but the point is that the loss should never happen when 
constraints are static when the callee knows them. When the callee does 
not, then a constraint must be passed to it.

>>>> Usability always trumps performance.
>>>
>>> That's the philosophy of languages like Python, not Ada.
>>
>> Ah, this is why Python is totally unusable? (:-))
> 
> I would tend to argue that it is indeed the case that you get dubious
> results when you put usability first. Ada puts
> readability/understandability, maintainability, and consistency first (along
> with performance). Those attributes tend to provide usability, but not at
> the cost of making things less consistent or understandable.
> 
> I wrote an article on this topic a year and a half ago that I wanted to
> publish on Ada-Auth.org. But I got enough pushback about not being "neutral"
> that I never did so. (I don't think discussing why we don't do things some
> other languages do is negative, but whatever.) I've put this on RR's blog at
> http://www.rrsoftware.com/html/blog/consequences.html so it isn't lost.

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.

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.

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.

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

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