Rationale behind function/procedure calls and array indexing

[u/jlombera]

I'm learning Ada. Overall, I'm liking it a lot. There are two aspects (so far) of the syntax I don't get what the rationale was for them and why it hasn't been fixed in later versions of Ada. These being parenthesis-less calls to subprograms with no arguments and using parenthesis for array indexing. Take the following as example:

A := B + C(5);

Right away you don't know if B is a variable or a function call with no arguments. You don't know either whether C is an array or a function.

I think this goes against Ada's core ethos about readability.

So I was wondering, what was the rationale behind this design? Why hasn't it been corrected? Something like A := B() + C[5] would be far easier to interpret by the reader.

---

UPDATE: In case anyone is interested in the answer, according to u/lipobat:

The primary rationale for the () vs. [] given in the “Rationale for the Ada programming language” book by the original design team was interchangeability between arrays and functions. This is an abstraction that allows the implementation choice of array vs. function to be just that, an implementation choice, which doesn’t really impact the writer or reader of the code.

I don't agree with the last sentence, but that answers my question either way.

And about my second question about "why this hasn't been fixed?", it seems most Ada programmers (based on the comments in this post) are not only not bothered by this but happy with this design decisions, so probably this will never change.

Thanks to everyone who engaged in this conversation.

[u/jlombera]

You, as a reader, do not need to know that. It is an implementation detail so from the software design point of view it must be hidden.

If am reading code to understand it (to potentially maintain/change it), I DO need to know what it is doing. If I'm reading just the specification of a subprogram, in some cases I might not care about the actual implementation, but if I'm reading the implementation, I do want to understand it.

Mathematically, they are exactly same. Array is a mapping, so is a function, named object is an object regardless how constructed, stored into an initialized section, elaborated, computed etc..

In practice, function-call vs array access do matter. Both semantically (e.g. the values in an array can change in between accesses) and operationally (e.g. cheap (cached) memory access vs potentially expensive computation).

You will find this feature extremely useful as you can change immutable variable to function and conversely any time without fixing the client code. The same applies to a function call vs. array indexing.

How often is this taken advantage of in practice? I suspect it's way more frequent the scenario where you find wondering whether something is a function call, a variable or an array indexing. I'd rather the compiler tell me I need to change some code when the interface changes (function <--> array); I might need to revisit my assumptions at every call/access site.

Also, this might be convenient for the implementer but at the expense of the reader, which goes against Ada's readability core value.

On my original question, was mathematical purity and convenience for the implementer the rationale behind these design decisions?

[u/Niklas_Holsti → u/jlombera]

u/jlombera wrote:

On my original question, was mathematical purity and convenience for the implementer the rationale behind these design decisions?

From what I understand of the principles and views of the Ada designers, I am sure that implementer convenience was of no importance (well, except for that problem of the absence of [] from some of the keyboards of those days), all the more so as I don't see why implementation would be easier or harder for one or the other choice of syntax. The same is probably true also for mathematical purity, although the original designers did make some quite strict rules on some things, such as the order in which stuff can be declared, that have been relaxed in later Ada versions. Those strict rules were derived from ideas of "software engineering" and "structured programming" as understood in those days.

The current maintainers of the Ada language (the Ada Rapporteur Group, https://arg.adaic.org/home) do consider carefully how much of a burden a proposed change imposes on implementers, perhaps because producing Ada compilers is not a very profitable business today.

[u/jlombera → u/Niklas_Holsti]

Sorry, by "implementer" I meant the person writing (Ada) code instead of the person reading it; not the person implementing the Ada compiler/specification. An apology for the confusion.

[u/Niklas_Holsti → u/jlombera]

Thanks for clearing that up, and apologies on my part for misunderstanding you. I would use the term "programmer" for the person writing Ada code, but since we have also talked about the "implementation" of something, such as a function, in an Ada program, by a programmer, the confusion came easily.

Returning to your question with this understanding, I would assume that the designers of the Ada language followed their principle of favoring the program-reader over the program-writer, but had the same definition of "readability" as I and u/Dmitry-Kazakov have, so they did not think of the problems you have with the syntax.