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 X-Received: by 2002:a6b:6705:: with SMTP id b5-v6mr5419624ioc.35.1527601215542; Tue, 29 May 2018 06:40:15 -0700 (PDT) X-Received: by 2002:a9d:5543:: with SMTP id h3-v6mr1236435oti.13.1527601215395; Tue, 29 May 2018 06:40:15 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.gegeweb.eu!gegeweb.org!news.redatomik.org!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!85.12.16.70.MISMATCH!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.am4!peer.am4.highwinds-media.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!v8-v6no6473744itc.0!news-out.google.com!b185-v6ni5500itb.0!nntp.google.com!u74-v6no6439867itb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Tue, 29 May 2018 06:40:15 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=47.185.233.194; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 47.185.233.194 References: <55ce14eb-6b83-4ea0-a550-f9e1410d0b06@googlegroups.com> <51dfb377-1b3e-45ca-a211-158101efe557@googlegroups.com> <090d6eb2-9f52-4471-a22e-ce1bdf457188@googlegroups.com> <90f0f8da-dadd-4341-bc0f-dbda94b0516c@googlegroups.com> <137bcc76-2489-4557-979b-5efeecbd9289@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <02ca60ab-0cf6-45d6-bed5-0358d4f5763d@googlegroups.com> Subject: Re: Strings with discriminated records From: "Dan'l Miller" Injection-Date: Tue, 29 May 2018 13:40:15 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 5387 X-Received-Body-CRC: 1899044914 Xref: reader02.eternal-september.org comp.lang.ada:52761 Date: 2018-05-29T06:40:15-07:00 List-Id: On Tuesday, May 29, 2018 at 2:49:20 AM UTC-5, Dmitry A. Kazakov wrote: > On 2018-05-29 12:27 AM, Mehdi Saada wrote: > > I see, and I would expect a constant declaration M: constant nights.mes= sage :=3D nights.create("hello world); > > to have exactly the same implementation. I am right ? >=20 > Yes. Renaming temporary objects is probably a language design bug. Then submit an AI to launder the dirty laundry versus have this viewpoint v= etted by the full board of ARG experts to see whether this assertion has an= y merit at all. > But=20 > renaming is broken in so many ways that one more, one less does not make= =20 > much difference. >=20 > BTW, If I would allow renaming a function result, then that would have=20 > lazy evaluation/closure semantics. >=20 > > After all you do or not do exactly the same, as far as I understood. >=20 > There are subtle and not so subtle differences, like sliding or not=20 > array indices. >=20 > It is best to use rename only where it was originally intended, e.g. If you think that the ARG made a mistake in the wording of the _LRM_ to all= ow vastly more usage of RENAMES than =E2=80=9Cwhat* was originally intended= =E2=80=9D, then submit one or more AIs to launder the very-soiled dirty lau= ndry versus have this viewpoint vetted by experts to see whether it has any= merit at all. * as the Dmitry Standard Organization itemized below: > 1. for renaming long named objects/packages: >=20 > X : T renames A.B.C.D.E.X; >=20 > 2. for renaming view conversions: >=20 > X : T'Class renames T'Class (Y); >=20 > 3. for renaming array/list elements and record members: >=20 > for I in A'Range loop > declare > Current : T renames A (I); > begin > ... >=20 > 4. for resolving name clashes: >=20 > type T is new Integer; > function Integer_Add (Left, Right : Integer) > return Integer renames "+"; -- Going to override, so keep the old > function "+" (Left, Right : Integer) > return Integer renames "+"; -- The new one On Tuesday, May 29, 2018 at 4:31:17 AM UTC-5, AdaMagica wrote: > Dmitry's list is very good advice. Wait, we have an international standard for Ada that specifies big-time ind= ustry-trend* language features that need a de facto amendment =E2=80=98out = in the community=E2=80=99 (apparently: documented in only passing commentar= y on c.l.a) to amend the international standard in ways that undermine the = ISO standard's normativeness? * Move-semantics have been a feature-set that have received extraordinarily= -focused attention to add to add them to the C++ ISO standard for multiple = years running now: C++11, C++14, C++17, and perhaps some fine tuning in th= e next C++2X as well. Either 1) RENAMES is an awesome language feature with many valid uses deriving fro= m the way RENAMES is officially specified in Ada's international standard (= e.g., that shows C++ how its move semantics should have been done much more= readably, much simpler). or 2) the uses of RENAMES other than those on Dmitry Standard Organization's l= ist above is a big pile of dog dung that needs AIs filed to officially depr= ecate RENAMES's unwise excesses in future editions of Ada's international s= tandard. It seems that the Law of Excluded Middle applies here: a) either restricting RENAMES's usage to only Dmitry Standard Organization= 's list above is awesome & wise or b) RENAMES as officially written into Ada's ISO international standard is a= wesome & wise in permitting RENAMES's full breadth of usages, including Sha= rk8's above.