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: Wed, 2 Dec 2015 14:06:04 +0100 Organization: A noiseless patient Spider 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: nonlegitur@futureapps.de Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Wed, 2 Dec 2015 13:03:39 -0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="b96887e80893c84a90c3007226ca0d1c"; logging-data="23552"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+TsWHazMD9S79TX3ESyJj+JKtY6DhoY1o=" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 In-Reply-To: Cancel-Lock: sha1:llQxvr94qscWdhTsfIg7pH5HD3g= Xref: news.eternal-september.org comp.lang.ada:28617 Date: 2015-12-02T14:06:04+01:00 List-Id: On 01.12.15 18:58, Dmitry A. Kazakov wrote: > Less defined by the RM then better. (OK, yet, taking this to absurd extremes, the ideal language would be undefined...) > Any predefined semantics is > a necessary evil. If not necessary, then just evil. How much predefined semantics is (un)necessary? In what circumstances? How much less will be more productive? And conducive to correct use of the language? How? (request for example below) For example, Apple is making "object properties" (dot notation) a convenience for connecting them to key-value coding. >> 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) Right. Also, the programmer might want ways of expressing volatility of virtual components, of addressing representation issues, etc. In this regard, could there be a novel approach to protecting access when defining ".X" instead of defining a plain old prim_op? > For *any* legal construct the compiler should emit > code with a predictable effect. Otherwise the language is ill-defined. Of course, what matters is the kind of predictability that a reviewer needs in order to check, efficiently, that the compiled code is of a kind that he could have predicted. This kind of efficient predictability suffers the more, I think, the more the programmer takes hold of defining things. Unless---which is why I'm asking--- the compiler can still manage to restore predictability in terms that are language terms of a kind that provide for said efficiency. So that no need for further study of the program's own definitions arises. > I don't see how Employee.Salary is less readable, > predictable, etc than Get_Salary(Employee). I'll be fine with ".X" if it offers any real benefit at virtually no cost. So, how will a record abstraction be usefully different from a private type? Can you give an example, say, built around procedure Op (X : ...; V : record'Class); -- (sic) I'm not opposed to new notations ("Who cares?" applies here ;): For example, I have often longed for a notation that expresses message sending. Related to that, in Ada terms, sequential calls look like concurrent calls. I don't always like that, because in one sense they are fundamentally different and I may want to state that they are. Granted, when calls are near "select", context does suggest "non-sequential".