comp.lang.ada
 help / color / mirror / Atom feed
From: "Randy Brukardt" <randy@rrsoftware.com>
Subject: Re: Is this a bug?
Date: Tue, 31 Dec 2019 15:50:49 -0600
Date: 2019-12-31T15:50:49-06:00	[thread overview]
Message-ID: <qugfrp$b0t$1@franka.jacob-sparre.dk> (raw)
In-Reply-To: d770cfc3-0d99-4b4f-af61-22e9ec849ba7@googlegroups.com

"Optikos" <optikos@verizon.net> wrote in message 
news:d770cfc3-0d99-4b4f-af61-22e9ec849ba7@googlegroups.com...
...
>Another moral to the story:
>This is a reason for language designers to not import some other language's 
>syntax
>in .verbatim. (in Ada95) just because all the cool OO kids were doing 
>member-dot
>syntax (during the late-1980s & 1990s).  Perhaps a quite-visual 
>multi-character
>token would have been better (e.g., dot-colon .: as a metaphor for zoom-in
>magnification or colon-dot :. for drill-down to a part within the whole). 
>Or perhaps
>tilde (~) or commercial-at (@) or back-tick (`) would have been better, if 
>a
>single-character token was the only option.

We thought about that, but Ada has always had prefix calls for task entries 
(all the way back to Ada 83) and for protected operations in Ada 95. 
Extending and normalizing that notion for tagged objects made more sense 
than inventing yet another similar notation.

In addition, the model of Ada has been that array indexing and function 
calls are syntactically interchangeable. It makes sense to use a similar 
model for components/subprogram calls.

The best possible fix here would be to find some alternative notation for 
record components so that there would be a work-around in case the primary 
notation doesn't work. That's the overall scheme for Ada: there is always a 
(lengthy) way to write something when a shorter form becomes impossible 
because of a conflict. The lack of such an "escape hatch" for record 
components leads to adopting a suboptimal rule.

That probably has to wait for a reimagined Ada, however, since it wouldn't 
be compatible. There's plenty of things that Ada got wrong at some point or 
other that we can't change because of compatibility concerns (overloading of 
objects is probably at the top of that list for me). Whether those 
improvements would be enough to encourage moving to a different, somewhat 
incompatible Ada is unclear.

                        Randy.


  reply	other threads:[~2019-12-31 21:50 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-30 15:44 Is this a bug? reinert
2019-12-30 17:51 ` Anh Vo
2019-12-30 18:41   ` Niklas Holsti
2019-12-30 19:50     ` reinert
2019-12-30 20:11       ` Dmitry A. Kazakov
2019-12-30 23:16     ` Randy Brukardt
2019-12-31 19:40       ` Optikos
2019-12-31 21:50         ` Randy Brukardt [this message]
2020-01-02  9:34           ` Dmitry A. Kazakov
2020-01-03  7:26             ` reinert
2020-01-03  7:35             ` reinert
2020-01-03  8:37               ` Dmitry A. Kazakov
2020-01-04  0:42                 ` Randy Brukardt
2020-01-05 13:32                   ` reinert
2020-01-06 10:43                     ` J-P. Rosen
2020-01-06 12:19                       ` Tero Koskinen
2020-01-17  9:54                 ` reinert
2020-01-17 10:08                   ` Dmitry A. Kazakov
2020-01-17 22:14                   ` Randy Brukardt
2019-12-31  6:08     ` J-P. Rosen
  -- strict thread matches above, loose matches on Subject: below --
2004-09-23  0:52 Wojtek Narczynski
2004-09-23  8:35 ` Wojtek Narczynski
2004-09-23 14:52   ` Nick Roberts
2004-09-23 22:26     ` Brian May
2004-09-24  0:28       ` Stephen Leake
2004-09-24  0:57         ` Jeffrey Carter
2004-09-24 12:47         ` Wojtek Narczynski
2004-09-25  0:17           ` Brian May
2004-09-24 12:37       ` Wojtek Narczynski
2004-09-23 11:27 ` Jeff C r e e.m
2004-09-24  0:30   ` Stephen Leake
2004-09-24  1:49     ` Jeff C r e e.m
2004-09-25 12:59       ` Stephen Leake
2004-10-04 16:36         ` Warren W. Gay VE3WWG
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox