From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Subject: Re: Map iteration and modification
Date: Fri, 5 Jan 2024 12:51:50 +0100 [thread overview]
Message-ID: <un8qgm$50cc$1@dont-email.me> (raw)
In-Reply-To: <un7nqe$3rs9n$1@dont-email.me>
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
next prev parent reply other threads:[~2024-01-05 11:51 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-28 13:53 Map iteration and modification DrPi
2023-12-28 13:59 ` DrPi
2023-12-28 16:06 ` Dmitry A. Kazakov
2023-12-28 17:57 ` DrPi
2023-12-29 3:20 ` Randy Brukardt
2023-12-29 9:51 ` Dmitry A. Kazakov
2023-12-29 15:03 ` G.B.
2023-12-29 16:52 ` Dmitry A. Kazakov
2024-01-01 19:27 ` G.B.
2024-01-01 20:55 ` Dmitry A. Kazakov
2024-01-02 16:40 ` G.B.
2024-01-02 20:57 ` Dmitry A. Kazakov
2024-01-03 3:22 ` Randy Brukardt
2024-01-03 4:05 ` moi
2023-12-30 7:21 ` Randy Brukardt
2023-12-30 11:07 ` Dmitry A. Kazakov
2024-01-03 3:15 ` Randy Brukardt
2024-01-03 10:04 ` Dmitry A. Kazakov
2024-01-04 4:07 ` Randy Brukardt
2024-01-04 11:28 ` Dmitry A. Kazakov
2024-01-05 2:00 ` Randy Brukardt
2024-01-05 9:26 ` Simon Wright
2024-01-05 11:51 ` Dmitry A. Kazakov [this message]
2024-01-06 7:25 ` Randy Brukardt
2024-01-07 15:06 ` Jeffrey R.Carter
2024-01-09 4:46 ` Randy Brukardt
2024-01-09 5:56 ` when-clauses (was Re: Map iteration and modification) Lawrence D'Oliveiro
2024-01-09 9:43 ` Map iteration and modification Jeffrey R.Carter
2024-04-17 10:12 ` Cóilín Nioclás Pól Glostéir
2024-01-06 2:54 ` “Usability” (was Re: Map iteration and modification) Lawrence D'Oliveiro
2024-01-06 7:03 ` "Usability" " Randy Brukardt
2024-01-06 8:14 ` Niklas Holsti
2024-01-06 23:41 ` Lawrence D'Oliveiro
2024-01-07 1:21 ` J-P. Rosen
2024-01-09 15:19 ` Bill Findlay
2024-01-09 20:30 ` Lawrence D'Oliveiro
2023-12-29 3:08 ` Map iteration and modification Randy Brukardt
2023-12-29 13:53 ` DrPi
2023-12-30 6:29 ` Randy Brukardt
2023-12-31 13:56 ` DrPi
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox