Re: Ada syntax questions

[Andreas ZEURCHER <ZUERCHER_Andreas@outlook.com>]

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: 
> >> 
> >>>> Why would you care? 
> >>> 
> >>> Calling a function can have side effects. Accessing an array or a 
> >>> variable can't have side effects. 
> >> 
> >> Untrue. Both array and variable access have side effects on the 
> >> registers, on the cache, on the process memory paging, in the form of 
> >> exception propagation etc. Even direct effects on the outside world are 
> >> possible when using machine memory load instructions. E.g. on some 
> >> hardware reading memory at the specific address location means physical 
> >> serial input. 
> > 
> > Dmitry, DrPi here is referring to side-effects as viewed from the functional-programming paradigm's perspective. Some programming languages have a "pure" designator (usually the keyword: pure) that assures that this subroutine and all invoked subroutines therein are pure (i.e., have no FP side effects). 
> > 
> > The side effects of which you speak are at the machine-code level: e.g., setting/clearing comparison flag(s), setting/clearing carry flag, setting/clearing overflow/underflow flag(s), evictions from L1/L2/L3 cache, (on RISC processors) latching an address in preparation of a load/store, and so forth. None of these are externally observable side effects from FP's perspective above the machine-code level. DrPi's FP goals are valid.
> Memory paging is pretty much observable. 
> 
> What you are saying is a question of contracts. The contract must 
> include all effects the user may rely on. The contract of a function may 
> include observable effects or have none (to some extent). 
> 
> 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.  Cute trick.  Advantageous in some situations.  But for people like DrPi who seek contractual assurance of FP-purity of (all?) invoked functions (and overt declaration of impurity of other functions), Ada's 1) implicit switcheroo there in unfortunate combination with Ada's 2) lack of flamboyantly advertising impurity in the replacement function does in fact violate the purity portion of the contract that the mere offset-into-array implementation had—and indeed •overtly• declared in its specification as a mere offset-into-array operation-of-unquestionable-purity.  It is okay for a 1970s Ada to not foresee this, because FP was not a mainstream programming practice back then.  (But, btw, it is not as okay for there to be a lack of HOLWGn each decade since the 1980s to revisit whether HOLWG1 forgot anything, where n>1, n∈ℤ.)  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.  And DrPi would enjoy seeing the compile-time errors emerge when some cavalier programmer over yonder changed an array index to an •impure• function invocation as contract violation.  The cute implicit switcheroo isn't evil, but the lack of compile-time detection of impurity in the switcherooed function is what is evil.

(While drinking tea as none of my business as the meme goes,) I actually claim that Ada's usage of parentheses for array indexing was merely happenstance copying the Fortran-PL/I-PL/1-Simula-PL/P-PL/M/CHILL heritage popular in the 1970s*, which itself mimicked mathematics' usage of parentheses around each matrix.  Because there was no way to represent mathematics' subscripts as the notation for indexing, the next best punctuation for matrix/vector indexing was borrowed:  parentheses.

* as opposed to the ALGOL58's, ALGOL60's, ALGOL68's, BCPL's, C's square brackets, so the big split was somewhere around 1957 for FORTRAN (and whichever predecessor languages influenced it) and 1958 for ALGOL58 (and whichever predecessor languages influenced it), as opposed to APL's ⍳ iota which uses neither parentheses nor square brackets to pull out an element since 1966

> >> All these effects are either desired parts of the implementation or else 
> >> bugs to be fixed. If desired, why do you care? 
> >>>> You seem to be implying this is bad; why? 
> >>> 
> >>> Reading the code can't tell you the writer's intentions. 
> >> What intentions? 
> > 
> > The intentions of the Ada programmer to design an overtly FP-pure or either an overtly FP-impure subroutine or an FP-impure subroutine by happenstance.
> Intentions are constraints expressed by contracts. Everything else is 
> implementation details. 
> 
> Ada programmers are not motivated by pureness of a subroutine. These are 
> totally irrelevant. What is relevant is the strength of the contract. 
> Functions without side effects are preferable just because they have 
> weakest preconditions and strongest postconditions. Side effects weaken 
> postconditions. 
> 
> For the clients these are of no interest, even less to deserve a 
> different syntax. The user must simply obey the contract whatever it be, 
> ignoring the implementation as much as possible. 
> 
> Ada's unified syntax is a great help here. I quite often replace arrays 
> and variables with functions. It would be great if literals were fully 
> equivalent to parameterless functions.
> -- 
> Regards, 
> Dmitry A. Kazakov 
> http://www.dmitry-kazakov.de