From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Is this a bug? Date: Tue, 31 Dec 2019 15:50:49 -0600 Organization: JSA Research & Innovation Message-ID: References: <1d96e0e1-7700-4947-9fcb-051a1203c703@googlegroups.com> Injection-Date: Tue, 31 Dec 2019 21:50:50 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="11293"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader01.eternal-september.org comp.lang.ada:57781 Date: 2019-12-31T15:50:49-06:00 List-Id: "Optikos" 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.