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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: operation can be dispatching in only one type Date: Tue, 1 Dec 2015 18:58:38 +0100 Organization: cbb software GmbH Message-ID: References: <1ephv5ugr5mib$.9ehadf3dddct$.dlg@40tude.net> <1nf8wc05tjtvf$.1ctjb9hsr0qsp.dlg@40tude.net> <8132c558-aec2-41f4-8024-4a75a2d497ae@googlegroups.com> <17c8a7kqoxvff.aa1raqev6xlu$.dlg@40tude.net> <75a4c7be-391d-4e5d-9e6e-23607132c943@googlegroups.com> <343b78d1-c1ba-40d3-af80-e18de45f2e3d@googlegroups.com> <11das66l3vhic$.1stkau3dqp6ld.dlg@40tude.net> <6y03ogx0fsk8$.n0ldd6cud931$.dlg@40tude.net> <51sbiz7sr8o7$.9wqd8z5xjlf8$.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: Sfz0eNwKWh4Uq03iti+GMw.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:28614 Date: 2015-12-01T18:58:38+01:00 List-Id: On Tue, 1 Dec 2015 17:05:28 +0100, in comp.lang.ada you wrote: > On 01.12.15 14:56, Dmitry A. Kazakov wrote: >> On Tue, 1 Dec 2015 12:19:02 +0100, G.B. wrote: >> >>> On 01.12.15 09:46, Dmitry A. Kazakov wrote: >> >>>> There is no reason why indexing or record member access >>>> should be less efficient when a user-defined implementation allowed, but >>>> not actually used. >>> >>> Sounds a bit like user defined aspects of compilation? >> >> It is not an aspect. Aspect is a view, characteristic, feature: >> >> http://www.thefreedictionary.com/aspect >> >> It means that aspect may not change the semantics. >> >> User-defined operation is exactly the opposite. It does not change the >> view. The object is still viewed as an array or a record. It is the >> semantics that gets changed. > > I take it that by "semantics" you mean the simplest meaning > of this word, viz. the operations that happen to become generated > for a ".X" function, say, as a consequence of compilation? > > If, however, a user may define what "rec.x" will do, then > this changes an aspect (sic) of compilation: what was previously > defined by the LRM (or would appear to be defined by the > language) does now seem to flow from the job of the programmer, > and becomes a property of the program, as it redefines certain > occurrences of ".". Who cares? Less defined by the RM then better. Any predefined semantics is a necessary evil. If not necessary, then just evil. > The compiler now needs to ensure something different when > translating "rec.x". The compiler needs to ensure what the programmer means (assuming correct language use) >>> What >>> guarantees would the compiler be able to generate that user >>> defined mechanics will work at the same level of assurance >>> as that of "regular" records? >> >> Generated guaranties? You lost me here. > > The current Ada language makes the compiler emit code for "Rec.X" > that is going to have a somewhat predictable effect. It does not make sense. For *any* legal construct the compiler should emit code with a predictable effect. Otherwise the language is ill-defined. The correct sentence is probably related to the program readability. That is up to the programmer and how he expresses the problem space in the language terms. I don't see how Employee.Salary is less readable, predictable, etc than Get_Salary(Employee). > If users are allowed to change the semantics of "rec.x", then > what level of assurance do we get? Same level as when the users are allowed to change the semantics of Foo(x), x+y etc. > We'd take away a basic building > block from the set of unequivocally predictable building blocks. Member extraction/setting operations is not a basic building block. Oh, I forgot, that you are in the anti-typed camp. So let me explain. There is *no* free operations. There are only types. The member operation .X is one of the built-in operations of the built-in record type. You don't loose it in no way if you allow *other* types have operations named this way or implementing same abstract interface. If you don't believe me, look at fully qualified names, they have "." inside. What a horror! -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de