From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Path: eternal-september.org!reader02.eternal-september.org!aioe.org!5WHqCw2XxjHb2npjM9GYbw.user.gioia.aioe.org.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Ada syntax questions Date: Sat, 19 Dec 2020 20:37:31 +0100 Organization: Aioe.org NNTP Server Message-ID: References: <5fdbde31$0$6455$426a74cc@news.free.fr> <86im8ylnj4.fsf@stephe-leake.org> <5fdde913$0$3238$426a74cc@news.free.fr> <7a72951a-5a0c-42d6-ad30-357a43883b6fn@googlegroups.com> NNTP-Posting-Host: 5WHqCw2XxjHb2npjM9GYbw.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 Content-Language: en-US X-Notice: Filtered by postfilter v. 0.9.2 Xref: reader02.eternal-september.org comp.lang.ada:60895 List-Id: On 2020-12-19 19:40, Andreas ZEURCHER wrote: > On Saturday, December 19, 2020 at 11:49:12 AM UTC-6, Dmitry A. Kazakov wrote: >> On 2020-12-19 18:13, Andreas ZEURCHER wrote: >>> On Saturday, December 19, 2020 at 6:40:28 AM UTC-6, Dmitry A. Kazakov wrote: >>>> On 2020-12-19 12:50, DrPi wrote: >> If contracts were indeed relevant to the syntax then functions without >> contracted side effects must have been called using [] instead of (). >> >> No? Then it is not about the contracts. > > As witnessed by your final sentence quoted below and multiple other replies along this thread, the key tactical advantage of Ada's usage parentheses for array indexing is to accomplish a switcheroo days, weeks, months, years, or decades later: to substitute a function invocation later for what was formerly an array index. Not substitute, but to provide whatever implementation necessary. In fact Ada is limited in terms of abstractions. There still exist things which cannot be implemented by user-defined subprograms. Ideally there should be none. Whatever syntax sugar, there should be always a possibility to back it by a user-provided primitive operation. > But for people like DrPi who seek contractual assurance of FP-purity of (all?) invoked functions (and overt declaration of impurity of other functions), If they are unsatisfied with the higher abstraction level of Ada, they can switch to lower-level languages where implementation details are exposed in syntax. The best we can do is to explain why such exposure is a bad idea. [ Conceptually Ada has nothing to do with FP and I sincerely hope it never will. ] > This 1970s faux pas in letting a silent slip-streamed switcheroo into the core contract-definition declaration mechanism of Ada (not comments! btw, tisk tisk) is merely some tarnish that an AdaNG (next-generation Ada) would fix: e.g., by mandating that all functions (and procedures?) shall be overtly declared & enforced to be pure or impure, which would then mean that only pure functions could substitute for array indexing is the ()-based switcheroo on which so many replies in this thread hang their hat. This would be highly undesired. On the contrary impure array implementations are all OK to implement various heuristics and caching schemes on the container side. In fact, Ada moved in that direction already by providing crude user-defined array indexing. Clearly as hardware evolves towards parallel architectures with partitioned memory, low-level arrays will be less frequently exposed in interfaces. Comparing older and newer Ada code we can see that trend of moving away from plain arrays. Furthermore, purity of implementation is not contract, per definition of. Purity is a non-functional requirement. There is only few areas of interest for such: 1. Compile-time evaluation/initialization of static objects and constraints. 2. Optimization, especially in the cases fine grained parallelism. In any case there is no reason to reflect that in the syntax, whatsoever. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de