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!.POSTED!not-for-mail From: "G.B." Newsgroups: comp.lang.ada Subject: Re: operation can be dispatching in only one type Date: Tue, 1 Dec 2015 17:05:28 +0100 Organization: A noiseless patient Spider Message-ID: References: <04eb6626-644b-4b16-a329-c35659a9fbe2@googlegroups.com> <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: nonlegitur@futureapps.de Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Tue, 1 Dec 2015 16:03:03 -0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="b96887e80893c84a90c3007226ca0d1c"; logging-data="26840"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18CFFZ64N63yYX5tAHFIW24I9A7XQS1L3A=" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 In-Reply-To: <51sbiz7sr8o7$.9wqd8z5xjlf8$.dlg@40tude.net> Cancel-Lock: sha1:jieYPdTO0pGjU7+mXdPyUtgEnUE= Xref: news.eternal-september.org comp.lang.ada:28613 Date: 2015-12-01T17:05:28+01:00 List-Id: 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 ".". The compiler now needs to ensure something different when translating "rec.x". >> 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 so driven by what it the LRM says. That much is a guaranteed outcome. If users are allowed to change the semantics of "rec.x", then what level of assurance do we get? We'd take away a basic building block from the set of unequivocally predictable building blocks. Is it hubris or are there hidden powers in overloading what now are non-operators?