Re: Real syntax problems in Ada

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

On 29.08.12 12:43, stefan-lucks@see-the.signature wrote:

> Indeed, the syntax for declaring a generic something (after the keyword 
> "generic" the parameters come first, and the something and its name comes 
> last) is counter-intuitive, different from any other declarations, and 
> hurts readability. Consider the following simple example:
> 
>    generic
>       type Item is private;
>       type Many_Items is array(Positive range <>) of Item;
>       with function "<"(Left, Right: Item) return Boolean is <>;
>    function Minimum(List: Many_Items) return Item;
> 
> Ask programmers without Ada experience what this is. Most would read this 
> as a generic declaration of something -- but how many would read this as 
> the generic declaration of a function called "Minimum"?

It is good to see a reference to at least one of the touchstones
of readability.


> Your idea seems to be to alternatively write the above declaration as 
> 
>   generic function Minimum
>       (type Item is private; 
>        type Many_Items is Array (Natural Range <>) of Item; 
>        function "<"(Left, Right: Item) return Boolean is <>)
>    (List: Many_Items) return Item;
> 
> This would be a lot more readable.

(The touchstones of readability are not mentioned here.)

Why would a "(" be more readable? I'd like to 2nd any motion
for bracketing, but not in *this* way. One issue seems to be:
"Where do the generic formals end?"

The example replaces, in a sense, the keyword "function" after the
formals (Ada style) with a "(" (in suggested style).  There may be
more "(" among the formals, like there are in the declaration of
Many_Items above. When declarations of formals become a little more
involved, then a "(" may easily make it to the start of a line,
forcing the reader to judge whether or not this "(" is the start of
the function's parameter profile.  Thus, "if the indentation is
lost...", then the brackets will surely leave many at loss.  (I don't
think that resorting to counting pairs of matching brackets counts as
a solution.)  Because

*) the distance between the function's name and
   its parameter profile is non-zero, and likely large;

*) the distinction between the two kinds of parameters is blurred,
   not made clear, by overloading () once more;

*) using sequences of ()s here introduces ambiguity (in the mind
   non-compiler readers) as entry families already use
   sequences of ()s in a similar context, but with different
   meaning.

The real problem for the reader of Ada generics seems to be finding
the spot where the generic formals end.

Interestingly, this problem is semi-solved in C++ (and Parasail).
Semi-solved because C++ template syntax is notorious for its
qualities, including >>, but nevertheless, there is no bracketing
problem in the sense of brackets marking a start-of-thing, and an
end-of-thing:

template <
   bla bla
> class T : ...


Here, the right angle bracket lets the reader see end of generic
formals. Voil�, the usual block structure!

Far from wanting to recommend the syntax of C++---why, when even C++
programmers frown upon it, it seems as though, in Ada, the left
bracket named "generic" would need some kind of matching right
bracket, since then the words "package", "function", and "procedure"
will not need to convey two meanings in the case of generic units
(end of formals, and kind of unit).