Re: Why .ads as well as .adb?

[Brad Moore <bmoore.ada@gmail.com>]

On Thursday, June 6, 2019 at 1:29:30 AM UTC-6, Maciej Sobczak wrote:
> > > This style is promoted by all industrial coding standards (both
> > > C and C++ language standards examples, MISRA-C, JSF, HICPP, AUTOSAR,
> > > ...), so I don't get the argument about "rarity".
> > >
> > > Actually, I don't even know where to find something different.
> > 
> > The two most common layouts for C code are:
> [...]
> 
> Of course. But as pointed above, the vertically-aligned braces are promoted by all industrial coding standards and are used in code examples of the language standards themselves. And I see them in classic books. And I see them in major open source code bases.
> Hence my comment about the argument that "most" C code is smushed together. I just don't see that. (But I know Java coders who, when forced to put their dignity aside, would actually write C code this way.)
> 
> In either case (in both styles) the argument that "Ada's comb" is superior is just not convincing. Which might explain why every new programming language either adopts C-style braces or resigns from distinct bracketing altogether. The subsequent argument that the whole world is idiots would not be convincing, either - this apparently is an inherent property of our visual system that delimiters need be visible enough to be noticed, but should not dominate over the actual (delimited) content.
> 
> Note: sentences are delimited by dots. Just like the sentence you are reading right now. And parts are delimited by commas, just like, you know, the parts of this very sentence.
> And it worked for ages. And we are used to it so much that we would refuse anything different.
> 
> Why?
> 
> Because our very brains are wired exactly to expect that.
> 
> Do you think it would be better to have delimiters and separators that areQWERTY you knowQWERTY so bigQWERTY that they take significant part of the spaceQWERTY with huge terminatorsQWERTY tooQWERTY so that we can see them betterASDFGHJ?
> 
> I don't think soASDFGHJ.
> 
> ;-)

I think you are somewhat comparing apples and oranges here. A sentence in English is more comparable to a statement in Ada. The delimiter for statements in most programming languages including Ada is a semi-colon, which is a single character. I'm guessing semi-colon was chosen over period, as it is less ambiguous for floating point declarations, and otherwise is more noticeable with similar semantics in English.

More comparable to a declarative region in English text is the section title as can be found in outline paragraph titles, and in chapter titles.

Often such declarations provide some sort of number to uniquely identify the section of text, and a descriptive name that describes the text to follow.

For English text, some simplications can be applied, since typically all "declarative regions" are declaring the same variables of the same types, with different data for the object instances. A numerical section id, and a textual short description. In programming languages, these declarative regions are more complex typically, and more critical to understanding the text that follows. 

Typically such declarative regions are further distinguished with preceding blank space including a carriage return, possibly a new page, a unique (larger) font, and then followed by a carriage return, and more blank space.

Pick any book off your bookshelf, you'll likely see this same pattern.

If we truly believe that shortening the "syntax" of these declarative regions is a good idea, then we should eliminate the carriage returns, blank space, font changes, etc from the document sections and chapter headers of all the literature.

1.0 intoduction It was a dark and stormy night, ... 2.0 the early years Way back in the old days...
;-)

Having a longer sequence of text in the syntax for paragraph titles, even if only blank space, can be helpful. Some authors add to this with syntax including the word "Chapter" for example. It doesn't necessarily add a lot of clarity for the reader, but isn't considered annoying either.

I think a bigger issue is using the same syntax for multiple constructs. In languages like C, you typically need to use comments to label end braces for deeply nested code to assist readability. And comments can be misleading. In Ada, different constructs use different (but similar) syntax, such as "end loop", "end select" end {subprogram name}, with optional block labels, which aids the reader in understanding which declarative contruct is ending. And with optional labels also allows the compiler to confirm that what the reader sees matches what the compiler sees. 

Brad