Ada's Assembly Language Comments

Ada's Assembly Language Comments

[RC]

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?

There must be some opinions on this but the only justifications I have
heard seem rather spurious.  (For example: "a student once had
compilation problems when an open coment block went off the right hand
of the screen with an editor which had line wrapping turned off.")

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

RC1

Re: Ada's Assembly Language Comments

[Peter Hermann]

RC (rc1@clanchy.demon.co.uk) wrote:

> 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?

Because this is much much more practical in many aspects.
This, however, can only be appreciated by those,
who wrote tons of code themselves.

A serious note on the "block structure"dness of C comments:

They begin a comment with a   /*   (AFAIK ;-)
and end it with a             */

HOWEVER(!) there is no means of further enclosing like

    /*  surrounding text  /*  original text  */   surrounding text */ 

(as the syntax might suggest at first glance)
because the FIRST appearance of    */     will end all commentary.
I consider this paradoxon another unacceptable immaturity,
like so many others.

--
Peter Hermann  Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen
Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: Ada's Assembly Language Comments

[RC]

>> 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?
>
>Because this is much much more practical in many aspects.

Why?

>This, however, can only be appreciated by those,
>who wrote tons of code themselves.

... and are therefore assembly language programmers?

Again, why?

>A serious note on the "block structure"dness of C comments:
>
>They begin a comment with a   /*   (AFAIK ;-)
>and end it with a             */
>
>HOWEVER(!) there is no means of further enclosing like
>
>    /*  surrounding text  /*  original text  */   surrounding text */ 
>
>(as the syntax might suggest at first glance)
>because the FIRST appearance of    */     will end all commentary.
>I consider this paradoxon another unacceptable immaturity,
>like so many others.
>
>--
>Peter Hermann  Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de
>Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen
>Team Ada: "C'mon people let the world begin" (Paul McCartney)

True, this limitation in Ada doesn't imply that C doesn't have
limitations although C++ does seem to have had end of line comments
added in.  I don't deny their usefulness for documenting individual
lines of code.

I mentioned Modula 2 as it does have the nesting problem sorted and it
seems strange that a language as powerful as Ada would overlook such a
simple and useful feature.

I would normally assume that "grown-ups" would only use C because the
piper payer called for that tune.


RC1

Re: Ada's Assembly Language Comments

[Peter Hermann]

RC (rc1@clanchy.demon.co.uk) wrote:
[snip]
> Why?
[snip]
> Again, why?

I really appreciate the course of the discussion after(!) these questions
because most of the reasons were explained in a way I could do no better.

[snip]
> I would normally assume that "grown-ups" would only use C because the
> piper payer called for that tune.

RC1,
BTW, Ada is freely available  ;-)
cheers,
Peter

--
Peter Hermann  Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen
Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: Ada's Assembly Language Comments

[Robert Dewar]

Peter Herman said

<<HOWEVER(!) there is no means of further enclosing like

    /*  surrounding text  /*  original text  */   surrounding text */

(as the syntax might suggest at first glance)
because the FIRST appearance of    */     will end all commentary.
I consider this paradoxon another unacceptable immaturity,
like so many others.
>>



More entertaining still is that dividing things by dereferenced values is
quite hazardous in C:

      x = a+b/*c;

and of course is made more hazardous by the fact that comments extend
over multiple lines.

Like most other things in Ada, the comment choice was not casual, the
decisions are very deliberate, and indeed this particular choice was
not a particularly controversial one, I think the arguments are
rather persuasive that block comments do NOT help the reader.

Sure they help the writer by requiring fewer keystrokes in the editor,
but the design of Ada does not care much about convenience to the
writer, it is dedicated to making the life of the code reader easier.

In Ada, if you see

    X := 3;

you know it is an assignment statement, you do not have to search
arbitrarily large amounts of surrounding text to see if perhaps it
might be a comment after all.

Even those people who do a lot of code writing do more code reading,
and appreciate this bias (even when they are reading their own code :-)

Re: Ada's Assembly Language Comments

[Kenneth W. Sodemann]

On Thu, 3 Jul 1997 13:09:02 +0100, RC <rc1@clanchy.demon.co.uk> wrote:

>
>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?
>

Why did the folks who defined Ada only define the one style of
commenting?  I cannot say, but I can speculate based on why, at the
company I work for, our C and C++ coding standards all but outlaw the
old /* .. */ comment style.

The " -- " (or " // " in the C/C++ world) style comments are "better"
(IMHO) for several reasons.  Most notably, they clearly define where a
comment starts, and ends, and it is almost impossible to "accidently"
comment out something.  In short, single like comments are safer.

The C and C++ coding standards where I work do not dis-allow the /* ..
*/ commenting style.  However, the coding standards _STRONGLY_ suggest
that the old fashioned C style comments _never_ be used for several
reasons.  All of the reasons given as notes in our coding standards
point to the fact that the newer " // " style comments are simply
safer.

/* For one thing, you do /* not have the problem where */
   this comment actually stopped on the previous line (though
   some C compilers can handle this). */

<WARNING:  Religious arguments ahead.>

Other reasons that the /* */ style comments are discouraged in our
C/C++ coding standards are that the // style comments are simply
prettier, and they make the comments stand out more.

ex:

//-------------------------
//  This is a comment on
//  several lines.
//------------------------- (a)

vs.

/*  This is a comment on
    several lines. */ (1)

or

/*-------------------------
    This is a comment on
    several lines.
-------------------------*/ (2)

or 

/*-------------------------
*   This is a comment on
*   several lines.
-------------------------*/ (3)

(1) would not stick out too well in actual code.
(2) is a slight improvement
(3) is even better, but at this point, you may as well used the //
style comments, which looked better in the first place.

This, of course, is more or less a religious argument, but I side with
the folks who state the (a) is the prettiest.

>There must be some opinions on this but the only justifications I have
>heard seem rather spurious.  (For example: "a student once had
>compilation problems when an open coment block went off the right hand
>of the screen with an editor which had line wrapping turned off.")
>

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.

--
Kenneth W. Sodemann
kwsodema@avistainc.com
http://www.avistainc.com
Speaking for myself, _not_ AVISTA Inc.

Re: Ada's Assembly Language Comments

[Richard A. O'Keefe]

kwsodema@avistainc.com (Kenneth W. Sodemann) writes:
>Why did the folks who defined Ada only define the one style of
>commenting?  I cannot say, but I can speculate based on why, at the
>company I work for, our C and C++ coding standards all but outlaw the
>old /* .. */ comment style.

Your C coding standard had better _not_ outlaw the old /* ... */ comment
style, because that is the ONLY comment style in C.  (C9X may adopt the
// comments from C++, but the public comment draft of C9X is not yet
with us, let alone C9X compilers.)

-- 
Four policemen playing jazz on an up escalator in the railway station.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: Ada's Assembly Language Comments

[Kenneth W. Sodemann]

On 4 Jul 1997 17:49:07 +1000, ok@goanna.cs.rmit.edu.au (Richard A.
O'Keefe) wrote:

>kwsodema@avistainc.com (Kenneth W. Sodemann) writes:
>>Why did the folks who defined Ada only define the one style of
>>commenting?  I cannot say, but I can speculate based on why, at the
>>company I work for, our C and C++ coding standards all but outlaw the
>>old /* .. */ comment style.
>
>Your C coding standard had better _not_ outlaw the old /* ... */ comment
>style, because that is the ONLY comment style in C.

Right, I should have said our "C++ coding standard".  My mistake.
Sorry about any confusion.  (It has been so long since we have
actually done anything here in straight C, thank God!! :) )

>(C9X may adopt the
>// comments from C++, but the public comment draft of C9X is not yet
>with us, let alone C9X compilers.)

That would be a nice improvement to the language.

--
Kenneth W. Sodemann
kwsodema@avistainc.com
http://www.avistainc.com
Speaking for myself, _not_ AVISTA Inc.

Re: Ada's Assembly Language Comments

[RC]

>>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

Re: Ada's Assembly Language Comments

[Dan Johnston D.B.]

In <0yQD$TAjanwzYw5m@clanchy.demon.co.uk> RC <rc1@clanchy.demon.co.uk> writes:

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

Pittman and Peters in "The Art of Compiler Design" give the example of the
following assignment statement in Modula 2.

  AnyString := '*) WriteString("Surprise!"); (*'

Attempting to comment out code including this statement results in the
appearance of the    WriteString("Surprise"); as an executable statment.

This is probably not too likely to occur in practice, but to me it kills
the idea that the comment design in Modula 2 is to be emulated.

Having written lots of both Ada and Modula 2,  (more Modula 2), I prefer
the Ada style provided that I have an editor - such as EMACS with Ada mode -
which allows me to easily comment and uncomment a section of code.

I can sympathise with the linewrapping problem, as I've been caught by that
also - but not in Ada.  For me, EMACS effectively solves this by putting
a \ in the last column when it line wraps.

  dan.            Dan Johnston.     dan@it.uq.edu.au

Re: Ada's Assembly Language Comments

[Robert Dewar]

ne thing to remember in this discussion of comments is that in the
Ada world, we ffavor the reader over the writer. Many arguments in favor
of the C style comments have been about favoring the ease of writing.
Fine, but we completely ignorte such arguments, well almost completely
ignore :-)

To me it is clear that the comment style of Ada is MUCH easier on the reader!

Re: Ada's Assembly Language Comments

[Robert Munck]

On Tue, 8 Jul 1997 18:19:31 +0100, RC <rc1@clanchy.demon.co.uk> wrote:
>>>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?

This entire discussion strikes me as somewhat old-fashioned, 
80-column card thinking.  I rarely see Ada source (or PL/SQL,
an Ada-derived DB language) that doesn't have the comments
rendered in italics, a distinguishing color, a proportional font,
or all three. I generally view code through a web browser and
edit it with one of several multiple-language-sensitive editors
that can do such things.  This obviously makes it easy to
be certain what parts of the source are comments.

I'm also opposed to the practice of "commenting out" source
code.  In addition to the problems discussed in this thread,
I find that when I need to add or omit code statically for 
some purpose (debugging, performance measurement,
etc.), I need to do so in several different places.  If I 
use comment delimiters, it's easy to miss one of the
changes, leaving the omission or inclusion partially 
done.  Using conditional statements and changing a
single static boolean eliminates this danger.

Bob Munck
Mill Creek Systems LC

Re: Ada's Assembly Language Comments

[Samuel Mize]

RC wrote:
> 
> 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?

Ada was designed for building highly-reliable, mission-critical
systems.  They had seen accidentally-unclosed comments consume
code up to the next comment termination.  They had also seen live
code accidentally "hidden" by comments, e.g.:

   text of C program appears  /* COMMENT BLOCK */
   to be over here on the     /* COMMENT BLOCK */ surprise!
   left side of the listing   /* COMMENT BLOCK */

Requiring matching open/close tokens (as C does not) solves the
first problem, but not the second.


>...The only justifications I have
> heard seem rather spurious.  (For example: "a student once had
> compilation problems when an open coment block went off the right hand
> of the screen with an editor which had line wrapping turned off.")

How about: Experienced professional programmers have accidentally
commented out good code and accidentally left in bad code, causing
system failures.  We're planning to build mission-critical and
life-critical systems, so we want to eliminate that risk.


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

It can be less convenient.  One has to learn how to comment
appropriately in the new language, rather than just doing things
the same as in another language.  On the other hand, one has to
learn how to do MANY things differently.

Ada is relatively self-documenting, if coded properly.  With good
identifiers and code structure, I find that line-by-line comments
are largely self-defeating: they reduce the clarity of the
program by cluttering the listing.  Most of my comments are blocks
of text, describing what the following block of code is doing.

I do occasionally miss being able to close a comment, but I never
miss finding that some idiot has accidentally put a space between
'*' and '/', and the critical code following that comment isn't
compiled (but appears on the listing).  I especially don't miss
being the idiot.

Sam Mize

Re: Ada's Assembly Language Comments

[Fergus Henderson]

Samuel Mize <smize@link.com> writes:

>>...The only justifications I have
>> heard seem rather spurious.  (For example: "a student once had
>> compilation problems when an open coment block went off the right hand
>> of the screen with an editor which had line wrapping turned off.")
>
>How about: Experienced professional programmers have accidentally
>commented out good code and accidentally left in bad code, causing
>system failures.  We're planning to build mission-critical and
>life-critical systems, so we want to eliminate that risk.

For further evidence that this happens even to experienced professional
programmers, here is an extract from /usr/include/sys/kern/queue.h
on the alpha-dec-osf3.2 system that I'm using.

	/*
	 *	Macro:		queue_init
	 *	Function:
	 *		Initialize the given queue.
	 *	Header:
	 *		void queue_init(q)
	 *			queue_t		q;	/* MODIFIED*/
	 */
	#define queue_init(q)	((q)->next = (q)->prev = q)

The only reason that this code compiles at all is that it is usually
#ifdef'd out.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: Ada's Assembly Language Comments

[Tucker Taft]

Why use "--" to introduce comments?

One little reason is that when you have large block comments,
you can do (line-oriented) searches and tell whether a given line 
found by your search is a comment line or not.  

With the C-ctyle /* ... */, or the #ifdef COMMENT_OUT ... #endif,
you may easily be confused by what is real code, and what is comment.

The biggest reason is readability.  There is never any doubt
what is a comment and what is not.

Interestingly, the only argument I have ever heard for
preferring the /* ... */ approach was to comment out large blocks
of code, but of course that only works if the large block
of code had no comments at all to begin with.

For what it is worth, when I write C, the only time I take advantage 
of the ability to stick a comment in the middle of a line of code
is to make up for the lack of named parameters when calling a function
(e.g. "do_sub(a, /* run_silent => */ true, /* run_deep => */ false);")

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA

Re: Ada's Assembly Language Comments

[RC]

>For further evidence that this happens even to experienced professional
>programmers, here is an extract from /usr/include/sys/kern/queue.h
>on the alpha-dec-osf3.2 system that I'm using.
>
>       /*
>        *      Macro:          queue_init
>        *      Function:
>        *              Initialize the given queue.
>        *      Header:
>        *              void queue_init(q)
>        *                      queue_t         q;      /* MODIFIED*/
>        */
>       #define queue_init(q)   ((q)->next = (q)->prev = q)
>
>The only reason that this code compiles at all is that it is usually
>#ifdef'd out.

True, but then it is 'C' isn't it?  Hardly the worlds definitive
standard for readable languages.

Again, if code can be nested, why not comments?



RC1

Re: Ada's Assembly Language Comments

[RC]

>RC wrote:
>> 
>> 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?

Samuel Mize wrote:

>Ada was designed for building highly-reliable, mission-critical
>systems.  They had seen accidentally-unclosed comments consume
>code up to the next comment termination.  They had also seen live
>code accidentally "hidden" by comments, e.g.:
>
>   text of C program appears  /* COMMENT BLOCK */
>   to be over here on the     /* COMMENT BLOCK */ surprise!
>   left side of the listing   /* COMMENT BLOCK */
>
>Requiring matching open/close tokens (as C does not) solves the
>first problem, but not the second.

The second problem isn't one really is it?

If a program is written:

   put (text); new_line;

No one would doubt that the new_line was an active statement.

(*
    A block of comments followed by code
    would be rather a messy style,
    but the meaning is apparent.
*)                                                     new_line;


>How about: Experienced professional programmers have accidentally
>commented out good code and accidentally left in bad code, causing
>system failures.  We're planning to build mission-critical and
>life-critical systems, so we want to eliminate that risk.

Compilers do their best to preclude this, programmers have their own
techniques of minimising their mistakes, making their intentions clear
and testing that the program does what the specification (and the
comments) say it should.

The problems with the *, /, /* and */ symbols in 'C' do exist and (* and
*) are possibly better.  The Pascal alternatives { and } might be better
still.

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

>It can be less convenient.  One has to learn how to comment
>appropriately in the new language, rather than just doing things
>the same as in another language.  On the other hand, one has to
>learn how to do MANY things differently.


I agree it can be done, I disagree that the lack of free flowing
comments makes Ada more readable.  I'm sure most programmers have had
compilation errors with comments but doubt that many pass through
undetected.


>Ada is relatively self-documenting, if coded properly.  With good
>identifiers and code structure, I find that line-by-line comments
>are largely self-defeating: they reduce the clarity of the
>program by cluttering the listing.  Most of my comments are blocks
>of text, describing what the following block of code is doing.

Agreed, which is why block structured comments should be allowed to flow
freely.


>I do occasionally miss being able to close a comment, but I never
>miss finding that some idiot has accidentally put a space between
>'*' and '/', and the critical code following that comment isn't
>compiled (but appears on the listing).  I especially don't miss
>being the idiot.


I would suggest that few programmers would accidentaly put a space in
the middle of a lexical symbol.

   if test the n            -- This would be spotted?
        do_something;
   end if;

When spaces appear in the middle of C end comments tends to be when
programmers have "turned off" the comment terminator in a piece of code
which has been temporarily commented out in a way that leaves it
available to be easily turned back on when the code is reactivated.

Proper nested comments would obviate the need for this.

After Ada there are other languages besides C.  Even if there weren't,
the non-existence of a feature does not preclude its possible
usefulness.


RC1

Re: Ada's Assembly Language Comments

[Joerg Rodemann]

RC (rc1@clanchy.demon.co.uk) wrote:
> Compilers do their best to preclude this, programmers have their own
> techniques of minimising their mistakes, making their intentions clear
> and testing that the program does what the specification (and the
> comments) say it should.

Really? Do they? What if your are not actually debugging the code but
trying to understand it for maintenance or porting purposes? Just recently
I was wondering how some piece of code could function. It contained some
really weird constructs. It was only them that I eventually recognized
the code was commented out. This is the major reason I only use these single
line comments now (using C++ and Java). They can save a lot of time i. e.
for someone not familiar with the code.

Surely this is just my humble opinion...

Joerg

--
rodemann@mathematik.uni-ulm.de | Dipl.-Phys. Joerg S. Rodemann
Phone: ++49-(0)711-5090670     | Flurstrasse 21, D-70372 Stuttgart, Germany
-------------------------------+---------------------------------------------
rodemann@rus.uni-stuttgart.de  | University of Stuttgart, Computing Center
Phone: ++49-(0)711-685-5815    | Visualization Department, Office: 0.304
Fax:   ++49-(0)711-678-7626    | Allmandring 30a, D-70550 Stuttgart, Germany

Re: Ada's Assembly Language Comments

[Samuel Mize]

RC,

I don't have some bizarre need to make you agree with the Ada
design decision, I'm just explaining the rationale behind it.

In many cases, I agree, block comments would make code easier
to write, and sometimes easier to read.  Line-delimited comments
are better for detecting editing errors.  (I believe it was
a requirement for the competing language designs that EOL end
comments.)  Agreed, this problem is greatly reduced if your
language tracks level of comment nesting, but it isn't
completely eliminated.

Since commenting is commonly used to switch blocks of code
in/out for testing or incremental deliveries, there is some
readability benefit to ensuring that each LOC is flagged if
it's commented out.

Both of these have caused real problems on real projects.

But I personally don't consider it an issue worth a lot of
sweat in any case.  As long as you don't have C-style "on/off"
commenting, you're MUCH safer.  Blocks would be a little
easier for explanatory comments, and a little more hazardous
for use during test.

Relative to the following quote, do bear in mind that I'm talking
about detecting editing accidents, not an intentional coding style.

Sam Mize

RC wrote:
> Samuel Mize wrote:
> 
> >Ada was designed for building highly-reliable, mission-critical
> >systems.  They had seen accidentally-unclosed comments consume
> >code up to the next comment termination.  They had also seen live
> >code accidentally "hidden" by comments, e.g.:
> >
> >   text of C program appears  /* COMMENT BLOCK */
> >   to be over here on the     /* COMMENT BLOCK */ surprise!
> >   left side of the listing   /* COMMENT BLOCK */
> >
> >Requiring matching open/close tokens (as C does not) solves the
> >first problem, but not the second.
> 
> The second problem isn't one really is it?
> 
> If a program is written:
> 
>    put (text); new_line;
> 
> No one would doubt that the new_line was an active statement.
> 
> (*
>     A block of comments followed by code
>     would be rather a messy style,
>     but the meaning is apparent.
> *)                                                     new_line;

Re: Ada's Assembly Language Comments

[Stuart Palin]

The thing I find irritating about Ada comments is the descision to 
construct the comment token out of a widely used mathematical symbol
rather than using some rarely used character or combining different
characters.  An accidental double key hit can lead to unintentional
commenting, and coupled with the long names encouraged in Ada it does
not seem unreasonable to suggest that an error of the form:

   long_name_a := long_name_b + long_name_c -- long_name_d - long_name_e
                  + long_name_f;

About the only way you can legislate against this in an automated syntax 
based style analysis program is to prohibit comments embedded in 
statements.

When Ada goes to the trouble of prohibiting double '_' (I believe for 
reasons of legibility) it seems doubly weird to use double '-' for 
comments.  Why not something like "!!", "%%", "##"?

--
Stuart Palin
Consultant Engineer
Flight Systems Division (Rochester)
GEC Marconi Avionics Ltd