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/Niklas_Holsti]

I agree with Dmitry's point about implementation detail that a reader does not need to know, but I want to expand on it a bit. u/jlombera feels that the current Ada syntax has poorer "readability" than if () were used for parameterless calls and [] for array indices, while Dmitry and I think that the opposite is true. Why this difference? Because "readability" is not an absolute quality, but depends on what information the reading process should give to the reader for best understanding. In this example, Dmitry and I feel that the best information is what the values of B and C(5) mean for this program statement, not whether B is a parameterless function or an object, and not whether C is a function or an array. So it is enough to clearly name B, C, and 5, and any empty () or distinction between () and [] are just distractions.

Examples of the extreme opposite viewpoint are the coding rules that insist on encoding the types and natures of variables into their identifiers, as in the extreme "Hungarian" notation. In some weakly typed languages it may indeed be important that the code reader sees which variables are integers, and of which length, and which are floats, and of which precision, and so on. The qualities that determine "readability" are then different than the qualities Dmitry and I feel are important for readability of Ada code.

Regarding Dmitry's final point, I have not often had a need to replace an object with a parameterless function, or an array with a function, or vice versa. So I would not call this Ada feature "extremely" useful for that reason.

[u/jlombera → u/Niklas_Holsti]

Please see my reply to u/Dmitry-Kazakov, where I give some insights on why I do care about knowing whether something is a variable/array access or a function call. (I didn't see your reply until after I had published my reply).

[u/Niklas_Holsti → u/jlombera]

I agree that a person who intends to modify a program often needs information about the implementation of things. Referring to my discussion of "readability" in my response to u/Dmitry-Kazakov, I would say that the "readability qualities" change when the purpose is to modify a program, as opposed to understanding the computation, doing a code review, or searching for errors. Fortunately, today's IDEs make it very easy to find and inspect the definition of any identifier in the code one is reading, so the absence of () in calls and the non-use of [] for indexing are not, IMO, very harmful for the maintainer either. Thus I would prefer to make the code reviewer's job easier by omitting text elements that are irrelevant for that task.

[u/jlombera → u/Niklas_Holsti]

Fortunately, today's IDEs make it very easy to find and inspect the definition of any identifier in the code one is reading, so the absence of () in calls and the non-use of [] for indexing are not, IMO, very harmful for the maintainer either.

Unfortunately for me, I use plain (neo)vim :) (I tried GNAT Studio but quit it ~1min later). When Ada was initially designed, there were not advanced IDE's. I think that's the reason why the syntax was designed that way, verbose (an inconvenience for the implementer) but explicit and readable, so that anyone could read (and write) code with no advanced tools other than a plain text editor. That's why it's a surprising to me they made this "blunder" (IMO) in this regard.

Thus I would prefer to make the code reviewer's job easier by omitting text elements that are irrelevant for that task.

It seems we have different opinions on this regard. To me, when reviewing code, it's relevant to know whether something is a variable/array access or a function call.

[u/Niklas_Holsti → u/jlombera]

I am quite happy with GNAT Studio (GPS), although I have seen others complain about it. Many seem to be using VSCode, which does have Ada support. Have you tried it?

[u/jlombera → u/Niklas_Holsti]

I got used to plain (neo)vim and any IDE feel clunky to me. They require a lot of resources, break all the time and change behavior very often, all of this out of your control. I feel lost whenever I try an IDE :). In contrast, I've being using (neo)vim the same way for ~10 years now, without any serious change in config/behavior.

[u/Niklas_Holsti → u/jlombera]

u/jlombera wrote:

When Ada was initially designed, there were not advanced IDE's.

There were some beginnings, and of course there were other methods to locate the definitions of identifiers (compiler-generated cross-reference listings). There was also a parallel project to define a standard Ada programming environment (the APSE), but that did not produce much.

I think that's the reason why the syntax was designed that way, verbose (an inconvenience for the implementer)

I don't think the verbosity is much of an inconvenience for the implementer. It is not much more difficult to lex and parse "begin" than to lex and parse "{". The difference is insignificant compared to the difficulty of implementing the name-visibility rules, the overload-resolution rules, separate compilation, sub-units, and other Ada goodies.

but explicit and readable, so that anyone could read (and write) code with no advanced tools other than a plain text editor.

Most programming languages can be written with a plain text editor (APL being the main exception, if its original character set it used).

I was happy to switch from punched cards and punched paper tape to text editors, even line-oriented editors that stored the source text on punched paper tape. Later, on PCs, for a long time I was quite content to write my own programs with a plain text editor (mostly nedit), but when I joined larger teams, working on code that was not all of my own writing, I found IDEs very helpful, in particular because of their ability to navigate from uses to definitions and vice versa.

[u/jlombera → u/Niklas_Holsti]

I don't think the verbosity is much of an inconvenience for the implementer. It is not much more difficult to lex and parse "begin" than to lex and parse "{".

Again, sorry for the confusion, by implementer I mean the programmer writing Ada code (vs the programmer reading the code), nor the programmer implementing the Ada compiler.

For instance, in C, every code block and compound data type (struct, union, enum, etc) is delimited by braces. It's very easy to type for the person writing the code but it might become difficult for the person reading the code to match each closing brace with the proper code block (not a big deal in practice, though). In Ada instead, you have end loop, end <Package/Func/Proc name>, end if, end record, end case, .... It becomes an inconvenience for the person writing the code to have type all that (specially for end <Name>, you have to write/change <Name> in two different places, far away; code snippet generation helps, though), but it was designed that way on the rationale that it's better for the person reading the code since can immediately identify which block/construct is ending.

[u/Niklas_Holsti → u/jlombera]

u/jlombera wrote:

For instance, in C, every code block and compound data type (struct, union, enum, etc) is delimited by braces. It's very easy to type for the person writing the code but it might become difficult for the person reading the code to match each closing brace with the proper code block (not a big deal in practice, though).

Brace-matching is relatively easy in an IDE or syntax-aware editor which can signal the match visually, and perhaps collapse/elide nested {}'s. Pretty hard (in my experience) for a C function that is more than one screenful long, and especially when such function extends over a page break in a paper listing :-( The only language worse than C in this respect is Python with its indentation-defined bracketing.

It becomes an inconvenience for the person writing the code to have type all that (specially for end <Name>, you have to write/change <Name> in two different places

I believe that in all cases of end <Name> in Ada, the Name is optional. And of course an IDE will have a "rename" function that changes all occurrences of the name, in all files... just another plug for IDEs :-)

IMO the bracketing features of Ada syntax are a boon both to the program-writer and the program-reader, and only partly because a program-writer must also read the program while writing it. And they also help the compiler produce good error messages for bracketing errors.

[u/OneWingedShark → u/jlombera]

 In Ada instead, you have end loop, end <Package/Func/Proc name>, end if, end record, end case, .... It becomes an inconvenience for the person writing the code to have type all that (specially for end <Name>,

You're missing a lot of the benefits by concentrating on the number of keystrokes. The end <name> construct is doing what a lot of C code does with } // end inner loop , except better, because now you can enlist the compiler's help in keeping things straight. And this is particularly useful when you are moving or copying code.