Re: Ada syntax questions

[Andreas ZEURCHER <ZUERCHER_Andreas@outlook.com>]

On Saturday, December 19, 2020 at 1:37:32 PM UTC-6, Dmitry A. Kazakov wrote:
> 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. 

No, Dmitry, that is where you are wrong.  In this regard, Ada is the lower-level, grungier, cruder, uncouther programming language, closer to assembly language or ALGOL60.  Languages that have a pure keyword (or equivalent elective designator for compile-time purity enforcement throughout a call-tree of subroutines) are the ones that are high-level, cleaner, more-sophisticated, more-refined programming languages, closer to the lofty heaven of mathematics.  This is actually a sad commentary on software engineering as a professed practice that we cannot even agree which programming-language feature-sets are higher-level versus lower-level, grungier versus cleaner, cruder versus more sophisticated, and uncouther versus more refined.

There is no good reason for Ada to lack all of the mechanisms to support FP (other than historical happenstance, then being substantially frozen in a Steelman mindset without any follow-on Stainlessman (arguably Ada95's, Ada2005's, Ada2012's would-be set of requirements that they have incrementally grown into) then Silverman (arguably SPARK's would-be set of requirements that is an ever-closer-to-finished work-in-progress) then Iridiumman then Goldman then Palladiummand then Platinumman evermore sophisticated requirements for a best-practices programming language to live up to as humankind's understanding of programming, system engineering, software engineering, and mathematics advances over time).

> [ 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. 

So is all of Ada's rich typing/subtypes.  Ada is simply capable expressing some categories of nonfunctional requirements of the design (e.g., rich typing) but not other more-modern categories of nonfunctional requirement (e.g., a pure keyword).