!standard  2.7(1)                                   17-09-07    AC95-00295/00
!class Amendment 17-09-07
!status received no action 17-09-07
!status received 17-09-02
!subject Block comments
!summary

!appendix

From: Frank Buss
Sent: Saturday, September 2, 2017  8:53 PM

I would like to have block comments. The rational for not having it, as e.g.
cited here:

https://stackoverflow.com/questions/27079641/why-is-there-no-multiple-or-block-comment-in-ada

is no longer valid with modern IDEs, because the IDE highlights comment
sections, so the programmer would see the omission of the closing delimiter.
But there are many advantages, like easier to read and to format header
information for a file, or as described in the Stackoverflow article,
temporary commenting source code while developing and debugging.

I guess this is possible with curly braces { }, as known from Pascal, because
currently they are illegal for Ada, except within literals and comments.
Implementation would be easy: ignore curly braces within single line comments
and literals, but parse it as block comment delimiters for the rest.

***************************************************************

From: Jeffrey R. Carter
Sent: Sunday, September 3, 2017  4:11 AM

Randy Brukardt has said repeatedly on comp.lang.ada that the ARG wants to
receive proposals that show problems not easily or clearly dealt with by Ada.
Proposed solutions, while welcome, are optional. Ada has been used
successfully for decades without block comments. The proposal seems to be a
solution to a non-problem.

Having used languages with block comments and with end-of-line comments, my
experience is that EOL comments are easier to read and understand than block
comments. Modern IDEs certainly decrease that difference significantly.
However, I still find myself looking at code without the benefit of a modern
IDE often enough (in e-mail, newsgroups, monochrome publications, and the
like) that I would not like the increased difficulty of reading block comments
in those situations.

Other than the claim of being easier to read, which I find to be false, the
argument for block comments is that it makes it easier to comment multiple
lines. Modern IDEs make it easy to comment and uncomment multiple lines. If
modern IDEs weaken the argument against block comments, they also weaken the
argument for them at least as much. Unlike reading code, for decades it has
been very rare for me to comment multiple lines without a modern IDE. Thus the
proposal's own argument argues against itself.

In light of the above, I recommend that this proposal be rejected.

***************************************************************

From: Jacob Sparre Andersen
Sent: Sunday, September 3, 2017  10:01 AM

> I would like to have block comments.
...
> is no longer valid with modern IDEs, because the IDE highlights 
> comment sections,
...

But what is the benefit, if you use a modern IDE?  Then you just mark the
block you want to turn into a comment and press the "turn-into-comment" key
combination.

***************************************************************

From: Randy Brukardt
Sent: Sunday, September 3, 2017  3:19 PM

...
> Randy Brukardt has said repeatedly on comp.lang.ada that the ARG wants 
> to receive proposals that show problems not easily or clearly dealt 
> with by Ada.

Thanks, Jeff, for saving me the time to write up these arguments. I fully
agree that the IDE argument doesn't hold water; if you are assuming IDE, then
surely that IDE can change commenting multiple lines trivially and a block
comment is not necessary. And certainly "I would like to have..." is one of
the weakest reasons for a language change.

***************************************************************

From: Joey Fish
Sent: Monday, September 4, 2017  3:18 PM

Another reason to disbar having both block- and EOL-comments is that the
inclusion of both encourages poor maintenance habits.

As an example, consider the following:

//* (Remove the first slash to make the for-loop code; add it to make
it a comment.)
for(int i =0; i < 10; ++i)
{
    a += i;
}
//*/

Things like the above are essentially manual conditional compilation and,
admittedly, [ab]used in debugging by myself are infinitely more likely to be
committed while the code is commented. If that happens, then the maintainer
is forced to evaluate the commented-out code as if its absence were the reason
for the current bug which can be difficult to determine.

***************************************************************