Re: Ada's Assembly Language Comments

[RC <rc1@clanchy.demon.co.uk>]

>>Why does Ada have only the " -- " assembly language style, in-line
>>comments and not block structured ones as in C or Pascal or better still
>>nested block structured comments as in Modula 2?

>Kenneth W. Sodemann
>kwsodema@avistainc.com
wrote:

>The flip side of this, of course, is what is so great about the "block
>styled" comment delimiters?  I can think of no advantage.

>>The elegance of user defined stucture of code seems to rather disappear
>>with the "knife and fork" nature of these comments.

>I do not under stand your "knife and fork" comment.  Please explain.


As in the knife and fork are tools applicable to eating rather than
engineering.

I still feel that programmers almost naturally recognise the block
structuring of modern languages.

The problems with comment nesting in 'C' were acknowledged, but were
elegantly dealt with in Modula 2.

Most languages have a fairly recognisable style and a few lines of
comments in free flowing English or whatever would normally be readily
distinguishable from lines of program code.  I accept that this would
not be the case where lines of code had been deliberately "commented
out".

Early languages and assembler use the end of a line to indicate the end
of a program statement.  This causes problems in higher level languages
where complex statements often flow over several lines.  The solution to
this is for the compiler to ignore "white space" except as the
separation of lexical symbols.  Statements are terminated by symbols
rather than carriage returns: <;>, <end>, <end if> and so on.

What is the difference when comments are bracketed by symbols rather
than white space?  For instance, most editors allow lines to wrap around
on the screen, this effectively hides the presence/ absence of carriage
returns.  (Perhaps compilers should ignore any characters after column
80, shades of Fortran?)

Can anyone tell whether the following is two lines: one commented out
the other a program statement or one long line?

--      index1   := first + second + third + fourth + fifth + sixth;
        index2   := second + third + fourth + fifth + sixth - seventh;

This example is obviously contrived but end of comment delimiters would
prevent it and reader confusion can be seen to be possible with either
form of comment.


When a comment is aimed at explaining a single line of code such as a
variable declaration then an end of line comment is appropriate.

Often, a whole subroutine can be effectively commented by a single
paragraph of text at the beginning, in which case bracketed comments
seem more appropriate.

In an intermediate case, several lines of code at a particular level of
indentation need an explanatory comment.  In this case indenting the
comments to the same level as the code helps to identify their
relationship.  Putting comment delimiters at the beginning of each line
either spoils the indentation or has to be placed at an awkward position
earlier in the line.

The Ada comment delimiter can touch the following comment but is better
given a space to make it more readable.

I'm sure the clarity of a book wouldn't be improved by having every line
preceeded by "-- " and I can't see that program clarity is improved
either.

The discussion about the use of "goto's" seems to indicate that few
would use them if they could avoid them although many defend them
fiercely.  Ada leaves the choice up to programmers and their
organisations.

I don't see why the use of block structured comments couln't have been
given the same treatment.  Bad programmers can always find ways to
misuse a language, good programmers make the best use of what is
available.  Anyone using comments is likely to be trying to assist
program readability and it is better to give their style as much
flexibility as possible.  A programming language can't enforce good
programming style.


RC1