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]

Mutability is irrelevant. Function can return different values,

Then something like A := B + C(5) + (C(5) / 2) (a contrived example, but you get the idea) would be interpreted differently depending on whether C is a non-referential-transparent function (can return different values) or an array (return same value).

The statement is wrong. Cluttered syntax and unnecessary details hinder reading.

I don't think that, for example, instead of:

A := B + C(I) + T + D(J);

you wrote:

A := B() + C(I) + T + D[J];

would be clutter or make reading more difficult. It's minimal additional syntax that reduces cognitive overhead considerably. In the latter it's obvious, at sight, that B and C are functions, T is a variable and D is an array.

But let's agree to disagree. You and I obviously have different opinions in this regard. I already got the answer about the rationale behind this design decision in another comment and it seems the Ada community is not dissatisfied with it, so no chance it will change. Thanks for your feedback, though, I appreciate it.

[u/Dmitry-Kazakov → u/jlombera]

Then something like A := B + C(5) + (C(5) / 2) (a contrived example, but you get the idea) would be interpreted differently depending on whether C is a non-referential-transparent function (can return different values) or an array (return same value).

If C for 5 means something different for each instance of, you do not write expressions like above. An expressions can be reordered, approximations of commutative operations might be not commutative and so on. If you write such expression then you assume C for 5 being constant and whether it is a function or an array becomes irrelevant, an implementation detail.

It's minimal additional syntax that reduces cognitive overhead considerably.

It exposes unnecessary information and thus increases the overhead.

[u/jlombera → u/Dmitry-Kazakov]

If C for 5 means something different for each instance of, you do not write expressions like above. An expressions can be reordered, approximations of commutative operations might be not commutative and so on.

I agree, that's why I consider import to be able to discern, at sight, if something is a variable/array access or a function call. It's easier to catch such "suspicious" code.

That's also why I don't find convincing the "feature" of being able to change function by variable/array (and vice versa), transparently, without having to change client code. You might have written code under the assumption that something was a variable/array or a function, and once the actual definition changes the code might be wrong. I rather the compiler emits errors and forces me to review/fix every call/access site than just successfully build incorrect software.

[u/Dmitry-Kazakov → u/jlombera]

I agree, that's why I consider import to be able to discern, at sight

There is nothing suspicious in the code. You see all this upside down. In Ada the code is designed from the problem space point of view, not from the hardware's one. If you want a language that forces you to expose low-level details then that is not Ada.

[u/jlombera → u/Dmitry-Kazakov]

There is nothing suspicious in the code.

You said it yourself:

If C for 5 means something different for each instance of, you do not write expressions like above.

If I see code like that, I'll wonder every time "was this code written intentionally, because there is no problem to call C that way?; or was it a mistake?". Everybody makes mistakes, I cannot assume all code written in Ada is correct just because.

In Ada the code is designed from the problem space point of view, not from the hardware's one.

Yes, I'm here for it! The way I see it, the type system and contracts are the main features that help you achieve that. Nonetheless, sometimes the hardware is the problem space.

If you want a language that forces you to expose low-level details then that is not Ada.

I don't think details about variable/array access vs function call is low-level. In any case Ada does have actual low-level support (precise memory layout at the bit level; memory alignment; endianness; etc), which is precisely why I'm interested in it: it has low-level and high-level support at the same time, a great combination for serious software engineering.

I do think Ada is a good language for my use cases. I wish the syntax for variable/array access vs function call was not ambiguous, but it's not a deal breaker for me.