Is there a way to do large block of source code comments

Is there a way to do large block of source code comments

[gdotone]

the book i'm using to learn ada has a little age to it. comments are done with --. and the authors suggest 

----------
--|
--|
----------

for block comments or banner comments. just wondering, has there been an addition to the language that has created something special for multiple line commenting.

is there a way to handle several lines at a time without having to do -- on every line?

like /* ...
           ...
        */  

used in C, could be used to handle multiple line comments.

Re: Is there a way to do large block of source code comments

[Jeffrey Carter]

On 09/01/2014 10:24 AM, gdotone@gmail.com wrote:
> 
> is there a way to handle several lines at a time without having to do -- on every line?
> 
> like /* ...
>            ...
>         */  
> 
> used in C, could be used to handle multiple line comments.

No, this was explicitly omitted. See the Ada-83 Rationale 2.1: "Single comments
that are larger than one line are not provided. Such comments would require a
closing comment delimiter and this would again raise the dangers associated with
the (unintentional) omission of the closing delimiter: entire sections of a
program could be ignored by the compiler without the programmer realizing it, so
that the program would not mean what he thinks. Long comments can be written as
a succession of single line comments, thus combining elegance with safety."

http://archive.adaic.com/standards/83rat/html/ratl-02-01.html#2.1

-- 
Jeff Carter
"People called Romanes, they go the house?"
Monty Python's Life of Brian
79

Re: Is there a way to do large block of source code comments

[Niklas Holsti]

On 14-09-01 20:24 , gdotone@gmail.com wrote:
> the book i'm using to learn ada has a little age to it. comments are done with --

Still the case.

> . and the authors suggest 
> 
> ----------
> --|
> --|
> ----------
> 
> for block comments or banner comments.

I use a simpler form for banners:

   (two blank lines)
   --
   ---   <banner heading/title>
   --
   (two blank lines)

Then I have an egrep script with the pattern

   '^ *(---|type|function|procedure|package|generic)'

which produces a nice, compact table of contents of a module.

I see no need for a special formatting of "block" comments, if by that
you mean comments extending over several lines of text.

<pet-peeve>
One of the worst mistakes in the programming field is the choice of the
name "comments" for the in-source documentation and description.
"Comments" suggests something secondary, incidental, unstructured,
incomplete. In-source documentation and description should IMO be
considered as or more important than the formal source code, should be
intentional, structured, grammatical, and complete (to some selected
criterion of completeness).
</pet-peeve>

> just wondering, has there been an addition to the language
> that has created something special for multiple line commenting.

No, fortunately IMO :-)

IMO, one of the best improvements in the C standard, lately, is the
inclusion of "//" comments.

> is there a way to handle several lines at a time without having
> to do -- on every line?

Only if you build your own preprocessor, or use the C preprocessor.

What is nice is to have an editor that can adjust/fill paragraphs in
multi-line comments, while keeping the "--" in their place. I believe I
once had such an editor, but my current ones do not have this ability.

Several C coding standards I've seen suggest that multi-line comments
should use the form:

   /* bla bla
    * more bla bla
    * even more bla bla
    */

which is no less onerous than the Ada "--" prefix, and uglier IMO.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: Is there a way to do large block of source code comments

[Anh Vo]

On Monday, September 1, 2014 10:24:49 AM UTC-7, gdo...@gmail.com wrote: 
> is there a way to handle several lines at a time without having to do -- on every line? 
> like /* ... 
>            ... 
>         */  
> 
> used in C, could be used to handle multiple line comments.

Block comment is not needed. Most editors have this capability. If you use GPS, just select text block then press Ctrl+dash. If you use Adagide, select the text block then select comment button.

A. Vo

Re: Is there a way to do large block of source code comments

[G.B.]

Niklas Holsti <niklas.holsti@tidorum.invalid> wrote:

> <pet-peeve>
> One of the worst mistakes in the programming field is the choice of the
> name "comments" for the in-source documentation and description.
> "Comments" suggests something secondary, incidental, unstructured,
> incomplete. 

The notions once associated with commenting suggest rather the
opposite of incidental, unstructured, or incomplete. Writing commentary,
before the age of computers, indicated the highest degree
of professionalism, both as regards the subject on which the comments
were made as well as the forms of treatment. Today, the term still has
a place in law, I think.

So it is the programming profession that has neglected what commenting
should mean. Perhaps it was a mistake to drop the word "comment"
from most languages after Algol 60 instead of trying to formally extend its
possibilities. Eiffel has tried to make it more useful with its "indexing"
clause
at the top of class definitions. Python stores a descriptive comment,
a string, with every def.

Ada 2012 aspect notation could add a tool-ready aspect that describes
an entity in brief:

  procedure Read (..., Item : out T)
     with Comment => "... short description ...",

Re: Is there a way to do large block of source code comments

[Niklas Holsti]

On 14-09-01 23:34 , G.B. wrote:
> Niklas Holsti <niklas.holsti@tidorum.invalid> wrote:
> 
>> <pet-peeve>
>> One of the worst mistakes in the programming field is the choice of the
>> name "comments" for the in-source documentation and description.
>> "Comments" suggests something secondary, incidental, unstructured,
>> incomplete. 
> 
> The notions once associated with commenting suggest rather the
> opposite of incidental, unstructured, or incomplete. Writing commentary,
> before the age of computers, indicated the highest degree
> of professionalism, both as regards the subject on which the comments
> were made as well as the forms of treatment.

Yep. But still "secondary", such as commenting on a work by some famous
author -- it may require high expertise, but the comments are not meant
to stand alone or have equal standing with the original work which is
being commented.

> So it is the programming profession that has neglected what commenting
> should mean. Perhaps it was a mistake to drop the word "comment"
> from most languages after Algol 60 instead of trying to formally extend its
> possibilities.

Nah - the word "comment" for in-source description should be replaced by
something better, both in writing and in speech.

> Ada 2012 aspect notation could add a tool-ready aspect that describes
> an entity in brief:
> 
>   procedure Read (..., Item : out T)
>      with Comment => "... short description ...",

That could be useful for ASIS tools (although I believe that ASIS
already has some way to access the comments for a declaration), but I
would object to using the word "Comment" as the aspect name, for the
reasons I have given.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: Is there a way to do large block of source code comments

[gdotone]

Thanks everyone.

g.

Re: Is there a way to do large block of source code comments

[Simon Wright]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:

> What is nice is to have an editor that can adjust/fill paragraphs in
> multi-line comments, while keeping the "--" in their place. I believe
> I once had such an editor, but my current ones do not have this
> ability.

Emacs ada-mode.

Re: Is there a way to do large block of source code comments

[G.B.]

On 01.09.14 22:53, Niklas Holsti wrote:
>> Ada 2012 aspect notation could add a tool-ready aspect that describes
>> >an entity in brief:
>> >
>> >   procedure Read (..., Item : out T)
>> >      with Comment => "... short description ...",
> That could be useful for ASIS tools (although I believe that ASIS
> already has some way to access the comments for a declaration), but I
> would object to using the word "Comment" as the aspect name, for the
> reasons I have given.

This aspect seems so easy to implement, yet so simple, useful,
and widespread (across languages) as to have a chance of being
acceptable as an addition to Ada. (GNAT, in particular, already
has Annotate, which is a lot more elaborate.)

Should I send this:

!topic An aspect for associating brief descriptions with declarations
!reference Ada 2012 RM 3, 6.1.1, K
!from Georg Bauhaus 14-09-02
!keywords aspects comments ASIS
!discussion

Starting with the Ada 83 style guide, there is advise on
commenting, a controversial yet much needed part of all
programs. The Ada language dispenses with any controversy by
simply providing the rules of “--” at the level of syntax. Tools
associating comments and declarations usually require some ad-hoc
convention that is not universal, which hinders integration. This
partly contrasts with Section 3.3 of the guidelines which state

  "o    Structure comments in headers so that information can be
        automatically extracted by a tool."


On the other hand, in Ada 2012, there now is a way for programmers
to "explain aspects of the code that are otherwise not
readily apparent." [ibid.]. This can be achieved, in part, by using
the contract related aspects of RM 6.1.1. Similarly, a standard
aspect for things still not readily apparent could be hooked to
an aspect, as explained below.

The focus of this aspect would be on indexes as found in books,
slightly adapted to the needs of programmers. For example, in
larger programming situations, it will be beneficial to have an
index of an Ada library that lists the entities declared therein
together with a short description, readable without reference to a
number of ad-hoc conventions for associating comments and
declarations. That is, for index style commenting to be useful
across projects, compilers, and tools, the name of a corresponding
aspect needs to be standardized.

It's value would be a string.

The idea is to have a very simple mechanism, easy to implement and
usable with tools simpler than ASIS (but not excluding the latter).
It is a compromise between today's implied, ad-hoc rules of comment
placement and a more express solution. The Java language is offering
@-keywords for this purpose; they are more elaborate, yet less
flexible.

An additional benefit of closer integration of "indexing comments"
with the language is that failing to update comments might be less
likely, because an aspect appears more pressing on change than
just about anything that can be put behind “--”, somewhere.

package Example
   with Indexing=> "declarations illustrating this submission"
is
    -- Not all comments are about one thing in particular.
    -- Not all comments are very brief.
    -- Some comments seem to have no reference at all.

    Buckets : Natural := 12
      with Indexing => "number of buckets configured",
        Atomic;

    function Drops (Bucket : Natural) return Natural
      with Indexing => "number of drops collected in Bucket",
        Post => (if Drops'Result = 0
                 then (not Is_Placed (Bucket) or No_Rain));
    -- TODO: replace Natural with a subtype for bucket numbering

end Example;

Re: Is there a way to do large block of source code comments

[kalvin.news]

> 
>     function Drops (Bucket : Natural) return Natural
> 
>       with Indexing => "number of drops collected in Bucket",
> 
>         Post => (if Drops'Result = 0
> 
>                  then (not Is_Placed (Bucket) or No_Rain));
> 
>     -- TODO: replace Natural with a subtype for bucket numbering
> 
> 
> 
> end Example;

While at it, why not adding "with todo => ..." as well ;)

Re: Is there a way to do large block of source code comments

[Adam Beneschan]

On Monday, September 1, 2014 12:08:21 PM UTC-7, Niklas Holsti wrote:

> One of the worst mistakes in the programming field is the choice of the
> name "comments" for the in-source documentation and description.
> "Comments" suggests something secondary, incidental, unstructured,
> incomplete. 

Which is probably an accurate description of how programmers used them when the term "comment" was first used.

I wouldn't call this a mistake, any more than I'd call it a mistake to refer to a memory dump as a "core dump" or to the program that translates from a high-level language as a "compiler".  [I'm not sure how much the term "core" is used now, but it was certainly used well past the time when ferrite cores all but disappeared.]  None of these terms makes literal sense now, but they made sense when they were introduced, historically, and the terms have stuck around even though their meanings have evolved.  We do need to remember that our terminology, like our programming language syntax and our technology, did not spring forth fully formed from somebody's head.

                                     -- Adam

Re: Is there a way to do large block of source code comments

[Simon Wright]

Adam Beneschan <adambeneschan@gmail.com> writes:

> I'm not sure how much the term "core" is used now, but it was
> certainly used well past the time when ferrite cores all but
> disappeared.

My Macbook (running Mavericks, the latest production version) has a
directory /cores for core files (which is empty at the moment, probably
because ulimit -c is still at the default (0)).

Re: Is there a way to do large block of source code comments

[Jeffrey Carter]

On 09/02/2014 08:01 AM, Adam Beneschan wrote:
> 
> I wouldn't call this a mistake, any more than I'd call it a mistake to refer
> to a memory dump as a "core dump" or to the program that translates from a
> high-level language as a "compiler".  [I'm not sure how much the term "core"
> is used now, but it was certainly used well past the time when ferrite cores
> all but disappeared.]  None of these terms makes literal sense now, but they
> made sense when they were introduced, historically, and the terms have stuck
> around even though their meanings have evolved.  We do need to remember that
> our terminology, like our programming language syntax and our technology, did
> not spring forth fully formed from somebody's head.

In 1974 I worked with an ancient Burroughs bookkeeping machine that had a little
box of core memory. It broke regularly, and when the repairman opened it up I
liked to look at the little metal donuts.

We still talk of dialing phone numbers and turning lights on and off, though
it's been a long time since rotary devices were used for those. We still even
talk of "a flash in the pan" and "going off half cocked", though few of us have
ever used a flintlock musket.

-- 
Jeff Carter
"I don't know why I ever come in here. The
flies get the best of everything."
Never Give a Sucker an Even Break
102

Re: Is there a way to do large block of source code comments

[Niklas Holsti]

On 14-09-02 18:01 , Adam Beneschan wrote:
> On Monday, September 1, 2014 12:08:21 PM UTC-7, Niklas Holsti wrote:
> 
>> One of the worst mistakes in the programming field is the choice of
>> the name "comments" for the in-source documentation and
>> description. "Comments" suggests something secondary, incidental,
>> unstructured, incomplete.
> 
> Which is probably an accurate description of how programmers used
> them when the term "comment" was first used.

True for some programmers, but not all of them.

There was also the problem with the interpreted languages like BASIC,
some of which stored the comments in RAM along with the executable
program -- if you wrote to many comments, your program no longer fit in
memory :-(

I actually had that problem once, with TRS-80 BASIC... so I wrote a
BASIC program to remove all comments from another BASIC source text.

> I wouldn't call this a mistake, any more than I'd call it a mistake
> to refer to a memory dump as a "core dump" or to the program that
> translates from a high-level language as a "compiler". 

Ok, you have a good point. I will in the future call it "one of the most
unfortunate choices of a word".

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: Is there a way to do large block of source code comments

[mockturtle]

> 
> 
> There was also the problem with the interpreted languages like BASIC,
> some of which stored the comments in RAM along with the executable
> program -- if you wrote to many comments, your program no longer fit in
> memory :-(
> 

Ah, memories... (in this case my own :-)

If I remember correctly, someone used REM lines to store data or little pieces of machine code (often assembled by hand, with the table of the opcodes, counting the instructions to determine the width of a relative jump).  Then you run it (with USR?) and since you forgot a POP inside a subroutine the computer would reset... 

Re: Is there a way to do large block of source code comments

[Randy Brukardt]

"G.B." <bauhaus@futureapps.invalid> wrote in message 
news:lu4fs5$q6q$1@dont-email.me...
...
> On the other hand, in Ada 2012, there now is a way for programmers
> to "explain aspects of the code that are otherwise not
> readily apparent." [ibid.]. This can be achieved, in part, by using
> the contract related aspects of RM 6.1.1. Similarly, a standard
> aspect for things still not readily apparent could be hooked to
> an aspect, as explained below.

If you're talking about aspects in general, they're defined in 13.1.1. This 
certainly wouldn't be a contract aspect (which is a Boolean-valued 
expression that can be ignored, see 11.4.2), so you ought to reference 
13.1.1. Nothing about aspects or contracts (in general) is defined in 6.1.1.

                           Randy.

Re: Is there a way to do large block of source code comments

[Randy Brukardt]

"Adam Beneschan" <adambeneschan@gmail.com> wrote in message 
news:7376f57a-aa89-4ca4-8b44-568dee994707@googlegroups.com...
...
> We do need to remember that our terminology, like our programming language 
> syntax and
> our technology, did not spring forth fully formed from somebody's head.

Unless it's Ada standard terms, like "progenitor" or "statically 
unevaluated" (and probably "elaboration" and "instantiation", although I 
wasn't around for those). Those literally appeared in someone's head when 
creating the associated wording. (Although there were other false starts.) 
Probably the exception that proves the rule.

                                          Randy.

Re: Is there a way to do large block of source code comments

[robin.vowels]

On Tuesday, September 2, 2014 5:04:21 AM UTC+10, Jeffrey Carter wrote:
> On 09/01/2014 10:24 AM, g.nospam@gmail.com wrote:
> 
> > 
> 
> > is there a way to handle several lines at a time without having to do -- on every line?
> 
> > 
> 
> > like /* ...
> 
> >            ...
> 
> >         */  
> 
> > 
> 
> > used in C, could be used to handle multiple line comments.
> 
> 
> 
> No, this was explicitly omitted. See the Ada-83 Rationale 2.1: "Single comments
> 
> that are larger than one line are not provided. Such comments would require a
> 
> closing comment delimiter and this would again raise the dangers associated with
> 
> the (unintentional) omission of the closing delimiter: entire sections of a
> 
> program could be ignored by the compiler without the programmer realizing it, so
> 
> that the program would not mean what he thinks. Long comments can be written as
> a succession of single line comments, thus combining elegance with safety."

When a block of code is to be omitted (temporarily or semi-permanently)
it's convenient to have something like /* and */ as comment markers.

It's also convenient to have comment markers for long blocks of comments.

Live parsing editors are useful tools, because they highlight
code segments (including comments).

The above quotation is mere hype, like the author's justification for omitting
exponentiation in Pascal, somehow more convenient to use log and exp instead!

Re: Is there a way to do large block of source code comments

[Jeffrey Carter]

On 09/02/2014 05:07 PM, robin.vowels@gmail.com wrote:
> 
> The above quotation is mere hype, like the author's justification for omitting
> exponentiation in Pascal, somehow more convenient to use log and exp instead!

Funny. It's easy enough to find C++ guidelines that recommend avoiding
multi-line comments because they're error prone. When those who like to use an
error-prone language recommend against a construct because it's error prone, it
must really be bad.

-- 
Jeff Carter
"I don't know why I ever come in here. The
flies get the best of everything."
Never Give a Sucker an Even Break
102

Re: Is there a way to do large block of source code comments

[Adam Beneschan]

On Tuesday, September 2, 2014 5:07:56 PM UTC-7, robin....@gmail.com wrote:

> > No, this was explicitly omitted. See the Ada-83 Rationale 2.1: "Single comments
> > that are larger than one line are not provided. Such comments would require a
> > closing comment delimiter and this would again raise the dangers associated with
> > the (unintentional) omission of the closing delimiter: entire sections of a
> > program could be ignored by the compiler without the programmer realizing it, so
> > that the program would not mean what he thinks. Long comments can be written as
> > a succession of single line comments, thus combining elegance with safety."

> When a block of code is to be omitted (temporarily or semi-permanently)
> it's convenient to have something like /* and */ as comment markers.
> 
> It's also convenient to have comment markers for long blocks of comments.
> 
> Live parsing editors are useful tools, because they highlight
> code segments (including comments).
> 
> The above quotation is mere hype, like the author's justification for omitting
> exponentiation in Pascal, somehow more convenient to use log and exp instead!

No, the quotation was not hype.  The problems caused by missing end-comment delimiters were real.

If you're thinking that this shouldn't be a problem because of "live parsing editors", you're right--in 2014.  But the document that you claim contains "mere hype" is the Ada 83 Rationale, which came out in (drum roll) 1983.  (Or perhaps a bit later, but the rationales weren't rationalizations created after the fact.)  Ada's development started several years before that.  The IBM PC came out in 1981, and it would have been some time before GUI editors were available (Eclipse was first released on 2001).  Before the PC, the video systems that programmers had available for developing programs would have been monochrome terminals with one font (but perhaps with some bold-face and reverse-video capabilities) and no graphics.  The screen-oriented editors I remember using for Pascal programming did not have any awareness of program syntax, like today's tools do.

Also, the same "live parsing editors" that are capable of coloring comments so that you can see that you've forgotten the end delimiter, are also capable of doing block comments.  Eclipse has a command to do this in Java programs, and it does so by adding // to the beginning of each selected line, not by using /* and */ (which in Java programs is normally only used for "javadoc" comments, comments that describe the the functionality and parameters of methods, that have a special format that can get translated to HTML).

                               -- Adam 

Re: Is there a way to do large block of source code comments

[gdotone]

On Tuesday, September 2, 2014 8:44:50 PM UTC-4, Jeffrey Carter wrote:

> Funny. It's easy enough to find C++ guidelines that recommend avoiding 
> multi-line comments because they're error prone. When those who like to use an 
> error-prone language recommend against a construct because it's error prone, it
> must really be bad.
> 
Even though i'm new to Ada and will use the convention of the language i agree with robin.  there is value in having such markers to allow multiline comments.

i personally would have preferred C programs only using /* .. */ for comments, C++ programmers using /* .. */ and //.
as for style C:

type function_name (...)
{
    ...
}

as for style C++:
same as C

as for java:
type function_name(...){
   ...
}

the rational given for not having a multiline comment delimiter may as well be used for having single line comments too.

type function_name(...){
   ...
}
this style was really about placing more printed line on a page anyway, but if only java used it, java programs would identifiable at a glance.

and, well, really for Ada, why not have:

program the_program_name is

instead of 

procedure the_program_name is

these are not words of war, of course, just observations from a newbie, who just may not know any better, and who loved Pascal...

please forgive the ramblings. :-) robin you are not alone.

Re: Is there a way to do large block of source code comments

[J-P. Rosen]

Le 03/09/2014 03:15, gdotone@gmail.com a écrit :
> Even though i'm new to Ada and will use the convention of the
> language i agree with robin.  there is value in having such markers
> to allow multiline comments.
What value? Saving some keystrokes when commenting large pieces of code?

Both Emacs and GPS have commands to comment the selection, so this is
really not an issue. OTOH, clearly seeing which lines are comments and
which ones are code is a plus. And yes, current editors use different
colors, but when you look at someone else's workstation with different
preferences, it may not be as obvious as one may think.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Is there a way to do large block of source code comments

[Brian Drummond]

On Tue, 02 Sep 2014 17:44:50 -0700, Jeffrey Carter wrote:

> On 09/02/2014 05:07 PM, robin.vowels@gmail.com wrote:
>> 
>> The above quotation is mere hype, like the author's justification for
>> omitting exponentiation in Pascal, somehow more convenient to use log
>> and exp instead!
> 
> Funny. It's easy enough to find C++ guidelines that recommend avoiding
> multi-line comments because they're error prone. When those who like to
> use an error-prone language recommend against a construct because it's
> error prone, it must really be bad.

And if you MUST use block comments, use a language that counts up /* 
tokens, counts down */ tokens, and returns to code when count = 0. 

Modula-2 was one language that did this - OK, the tokens were (* and *) - 
but it was immune to the "oops I missed a block comment in that section, 
so my hack went haywire" errors...

- Brian

Re: Is there a way to do large block of source code comments

[Georg Bauhaus]

On 03.09.14 01:33, Randy Brukardt wrote:
> "G.B." <bauhaus@futureapps.invalid> wrote in message
> news:lu4fs5$q6q$1@dont-email.me...
> ...
>> On the other hand, in Ada 2012, there now is a way for programmers
>> to "explain aspects of the code that are otherwise not
>> readily apparent." [ibid.]. This can be achieved, in part, by using
>> the contract related aspects of RM 6.1.1. Similarly, a standard
>> aspect for things still not readily apparent could be hooked to
>> an aspect, as explained below.
>
> If you're talking about aspects in general, they're defined in 13.1.1. This
> certainly wouldn't be a contract aspect

There's the huge misunderstanding. My fault not explaining it well.

Comments, as outlined, are definitely parts of contracts, and crucially so,
because a party can be held responsible if the comment is wrong.
"Contract based programming" is the important activity(!) that gives
asserting conditions the same significance as asserting comments.

- If a contract is wrong, the program needs to be fixed.
- If a comment is wrong, the, uhm, comment needs to be fixed???

(Ah. That's the engineers getaway car. I see.)

If comments can be "attached" to some declaration in the sense of 13.1.1,
that's a means to an end, thanks for the reference.

Won't send.

Re: Is there a way to do large block of source code comments

[Georg Bauhaus]

On 03.09.14 02:07, robin.vowels@gmail.com wrote:
> When a block of code is to be omitted (temporarily or semi-permanently)
> it's convenient to have something like /* and */ as comment markers.

Convenience for the writer.  Having been the one to study
someone else's™ code, broken as it was, in order to learn
what the heck it does, I hate this feature. And no, no shiny
magic in "powerful" editing equipment will work.

OTOH, I know how embarrassing it is for a programmer to
admit that he is not really skilled in using editors.

Re: Is there a way to do large block of source code comments

[gdotone]

On Wednesday, September 3, 2014 2:29:33 AM UTC-4, Stefan...@uni-weimar.de wrote:

> You don't need to agree with that decision by the Ada designers -- I am 
> not sure if I would agree with that either -- but you should understand 
> that it was something the Ada designers had carefully considered before, 
> very much unlike the Pascal example you gave, which was really an ad-hoc 
> decision, for the convenience of the compiler writer.
> 
> Now, I actually think it would have been possible to have block comments 
> the Ada way (and is still possible for Ada 202X): Allow block comments 
> (I'd suggest Pascal's "(*" and "*)" for their brackets but that is a 
> matter of taste). Just prohibit nesting! I.e., any "(*" inside a block 
> comment is a syntax error. Conventional "--" comments are allowed, and any 
> "(*" and "*)" inside a conventional comment are allowed and ignored (i.e., 
> not treated as block comment brackets). 
> 
> This language feature would allow to easily comment out large program 
> parts without safety issues. But I doubt there is actually much demand for  
> that in the Ada community!
> 

very good suggestion (* ...  *) 

-* *-, {* ... *}, [- ... -], --| ... |--, -| ... |-, *| ... |*, it's just a matter of finding the Ada 202X way :-)

perhaps, in 202X, there may be a way to include actual icons in the code as in apple's swift.
we could end up with some nicely designed bookends to handle the job.

g.

Re: Is there a way to do large block of source code comments

[Stefan.Lucks]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2534 bytes --]

On Tue, 2 Sep 2014, robin.vowels@gmail.com wrote:

> On Tuesday, September 2, 2014 5:04:21 AM UTC+10, Jeffrey Carter wrote:
>> On 09/01/2014 10:24 AM, g.nospam@gmail.com wrote:
>>> is there a way to handle several lines at a time without having to do -- on every line?
>>> like /* ...
>>
>>>            ...
>>
>>>         */
>> No, this was explicitly omitted. See the Ada-83 Rationale 2.1:
>> [...] Such comments would require a closing comment delimiter and this 
>> would again raise the dangers [...] without the programmer realizing it, so
>> that the program would not mean what he thinks.
>
> When a block of code is to be omitted (temporarily or semi-permanently)
> it's convenient to have something like /* and */ as comment markers.

Convenient: Yes! Safe: No!

The issue is that nesting /* and */ makes makes it difficult to parse 
programs -- not for the computer, but for humans. At the time Ada has been 
originally designed, syntax highlighting editors where not so common as 
they where today (to say the least). The designers of Ada decided to avoid 
these issues.

> The above quotation is mere hype, like the author's justification for 
> omitting exponentiation in Pascal, somehow more convenient to use log 
> and exp instead!

Nonsense!

You don't need to agree with that decision by the Ada designers -- I am 
not sure if I would agree with that either -- but you should understand 
that it was something the Ada designers had carefully considered before, 
very much unlike the Pascal example you gave, which was really an ad-hoc 
decision, for the convenience of the compiler writer.

Now, I actually think it would have been possible to have block comments 
the Ada way (and is still possible for Ada 202X): Allow block comments 
(I'd suggest Pascal's "(*" and "*)" for their brackets but that is a 
matter of taste). Just prohibit nesting! I.e., any "(*" inside a block 
comment is a syntax error. Conventional "--" comments are allowed, and any 
"(*" and "*)" inside a conventional comment are allowed and ignored (i.e., 
not treated as block comment brackets).

This language feature would allow to easily comment out large program 
parts without safety issues. But I doubt there is actually much demand for 
that in the Ada community!

------  I  love  the  taste  of  Cryptanalysis  in  the morning!  ------
     <http://www.uni-weimar.de/cms/medien/mediensicherheit/home.html>
--Stefan.Lucks (at) uni-weimar.de, Bauhaus-Universität Weimar, Germany--

Re: Is there a way to do large block of source code comments

[Pascal Obry]

Le mercredi 03 septembre 2014 à 01:23 -0700, gdotone@gmail.com a
écrit : 
> very good suggestion (* ...  *) 
> 
> -* *-, {* ... *}, [- ... -], --| ... |--, -| ... |-, *| ... |*, it's just a matter of finding the Ada 202X way :-)
> 
> perhaps, in 202X, there may be a way to include actual icons in the code as in apple's swift.
> we could end up with some nicely designed bookends to handle the job.

I bet this will never happen in Ada 202x or whatever. This feature is
too dangerous as others have said. It is too easy to have:

/* 
code1
/*
code2
*/

And to think that removing the second /* will actually activate code2.
And this is not fiction, I have seen this in real code. Of course here
it is easy to see, but on comments that span multiple pages...

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://v2p.fr.eu.org
  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Is there a way to do large block of source code comments

[Stefan.Lucks]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1095 bytes --]

On Wed, 3 Sep 2014, Pascal Obry wrote:

> Le mercredi 03 septembre 2014 à 01:23 -0700, gdotone@gmail.com a
> écrit :
>> very good suggestion (* ...  *)
>
> I bet this will never happen in Ada 202x or whatever. This feature is
> too dangerous as others have said. It is too easy to have:
>
> /*
> code1
> /*
> code2
> */

Did you actually READ the posting you just replied to?

That posting quoted my suggestion to introduce block comments where the 
opening bracket inside a block comment is plainly prohibited. I.e., the 
compiler would reject your above example with a syntax error in line 3.

This shows that there is a way to make block comments "safe" or "Ada-like" 
... if there is an urgent need for block comments in 202x.

BTW, I agree that I don't see this for "Ada 202x or whatever". I doubt 
that there is a real need for block comments.

------  I  love  the  taste  of  Cryptanalysis  in  the morning!  ------
     <http://www.uni-weimar.de/cms/medien/mediensicherheit/home.html>
--Stefan.Lucks (at) uni-weimar.de, Bauhaus-Universität Weimar, Germany--

Re: Is there a way to do large block of source code comments

[Shark8]

On 02-Sep-14 18:07, robin.vowels@gmail.com wrote:
>> No, this was explicitly omitted. See the Ada-83 Rationale 2.1: "Single comments
>> >that are larger than one line are not provided. Such comments would require a
>> >closing comment delimiter and this would again raise the dangers associated with
>> >the (unintentional) omission of the closing delimiter: entire sections of a
>> >program could be ignored by the compiler without the programmer realizing it, so
>> >that the program would not mean what he thinks. Long comments can be written as
>> >a succession of single line comments, thus combining elegance with safety."
>
> The above quotation is mere hype, like the author's justification for omitting
> exponentiation in Pascal, somehow more convenient to use log and exp instead!

No, the above is a quotation from the Ada Rationale.
It says that only single-line comments terminated by the end of the line 
were chosen so that there was no way that closing a multiline comment 
could be forgotten. Period.

> Live parsing editors are useful tools, because they highlight
> code segments (including comments).

What has this got to do with *anything* WRT comments?

Re: Is there a way to do large block of source code comments

[Pascal Obry]

Le mercredi 03 septembre 2014 à 17:12 +0200, Stefan.Lucks@uni-weimar.de
a écrit : 
> Did you actually READ the posting you just replied to?

Sure,  thanks for asking!

> That posting quoted my suggestion to introduce block comments where the 
> opening bracket inside a block comment is plainly prohibited. I.e., the 
> compiler would reject your above example with a syntax error in line 3.

Parsing a comment section???? Strange idea, I doubt this is reasonable. 
-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://v2p.fr.eu.org
  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Is there a way to do large block of source code comments

[Jeffrey Carter]

On 09/03/2014 01:28 AM, Stefan.Lucks@uni-weimar.de wrote:
> 
> Now, I actually think it would have been possible to have block comments the Ada
> way (and is still possible for Ada 202X): Allow block comments (I'd suggest
> Pascal's "(*" and "*)" for their brackets but that is a matter of taste). Just
> prohibit nesting! I.e., any "(*" inside a block comment is a syntax error.
> Conventional "--" comments are allowed, and any "(*" and "*)" inside a
> conventional comment are allowed and ignored (i.e., not treated as block comment
> brackets).

No, the Ada way would be

<identifier> : comment begin
   the identifier is required, here and on the "end comment"

   anything in here is ignored, including any

   end comment <other_identifier>;

   Of course, a "comment begin" without a matching "end comment" is an error,
   as is an "end comment" without a matching "comment begin".
end comment <identifier>;

-- 
Jeff Carter
"If a sperm is wasted, God gets quite irate."
Monty Python's the Meaning of Life
56

Re: Is there a way to do large block of source code comments

[Georg Bauhaus]

On 03.09.14 17:52, Pascal Obry wrote:
> Parsing a comment section???? Strange idea, I doubt this is reasonable.

It is standard practice in original SPARK, Java, and eLisp
to parse "comment sections". Also, languages such as Python
and Ruby parse commenting strings, similar to format strings.

They know the value of giving comments language status.

Re: Is there a way to do large block of source code comments

[Peter Chapin]

On 2014-09-03 13:48, Georg Bauhaus wrote:

> It is standard practice in original SPARK, Java, and eLisp
> to parse "comment sections". Also, languages such as Python
> and Ruby parse commenting strings, similar to format strings.
> 
> They know the value of giving comments language status.

In SPARK 2005 only special comments starting with --# where processed by
the SPARK tools and they had a very tightly controlled syntax.
Completely general comments starting with -- were still ignored.

The tricky part about parsing comments is that comments are intended to
be completely general and could contain arbitrary "line noise" for all
the compiler knows. Looking for too much structure in a general comment
could be problematic.

That said it doesn't seem impossibly difficult or awkward to scan
comments for sequences like "*/" or "*)" etc. I'm not sure I'd call that
"parsing" exactly but that's perhaps just a matter of definition.

Peter

Re: Is there a way to do large block of source code comments

[Adam Beneschan]

On Wednesday, September 3, 2014 8:52:12 AM UTC-7, Pascal Obry wrote:

> > That posting quoted my suggestion to introduce block comments where the 
> > opening bracket inside a block comment is plainly prohibited. I.e., the 
> > compiler would reject your above example with a syntax error in line 3.
> 
> Parsing a comment section???? Strange idea, I doubt this is reasonable. 

I don't see why not.  The language designers would have to come up with some simple rules, but this isn't hard:

The sequence (*, if not in a conventional comment, starts a block comment.  The comment ends with the next occurrence of the sequence *) that is not in a conventional comment.  Within a block comment, it is illegal for the sequence (* to appear except in a conventional comment.  A character sequence is "in a conventional comment" if it occurs anywhere between the sequence -- and the nearest subsequent end-of-line character. 

Maybe that's not exactly how it would be worded, but this rule would be clear and unambiguous, and it would be simple to implement.

Not that I'm saying it's a good idea.  I don't want to see this feature added to Ada.

                              -- Adam

Re: Is there a way to do large block of source code comments

[Stefan.Lucks]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 531 bytes --]

On Wed, 3 Sep 2014, Pascal Obry wrote:

> Parsing a comment section???? Strange idea, I doubt this is reasonable.

Hey, what do you think your Ada compiler is actually doing now? After 
"--", it searches for the line end. This *is* parsing.

My suggestion would be more complex, but only by a little.

------  I  love  the  taste  of  Cryptanalysis  in  the morning!  ------
     <http://www.uni-weimar.de/cms/medien/mediensicherheit/home.html>
--Stefan.Lucks (at) uni-weimar.de, Bauhaus-Universität Weimar, Germany--

Re: Is there a way to do large block of source code comments

[gautier_niouzes]

Le mercredi 3 septembre 2014 20:53:01 UTC+2, Adam Beneschan a écrit :

> I don't see why not.  The language designers would have to come up with some simple rules, but this isn't hard:
> 
> The sequence (*, if not in a conventional comment, starts a block comment.  The comment ends with the next occurrence of the sequence *) that is not in a conventional comment.  Within a block comment, it is illegal for the sequence (* to appear except in a conventional comment.  A character sequence is "in a conventional comment" if it occurs anywhere between the sequence -- and the nearest subsequent end-of-line character. 

Hey, not so easy! If you admit (* in a conventional comment within a block comment, then you need to specify that a *) is closing the nested (*, or perhaps not (then it would be closing the outer block comment), and also what happens if a *) is in a conventional comment but a one or more rows later. Is it closing the nested (* or the outer one ? Of course the question goes recursively with nesting...

I have some memories of headaches in the 80's or 90's when I was programming in Pascal with *) closing a {, or not, and so on. And I'm happy not having to deal with these block comments since then.

These block comments become very quickly very messy, especially because there may be unforeseen cases in the specification ( :-) ), and even if the specification is bullet-proof, compilers, parsers, editors or pretty printers may easily misinterpret the rules...
_________________________
Gautier's Ada programming
http://gautiersblog.blogspot.com/search/label/Ada
NB: follow the above link for a valid e-mail address

Re: Is there a way to do large block of source code comments

[Georg Bauhaus]

On 03.09.14 20:52, Adam Beneschan wrote:

> The sequence (*, if not in a conventional comment, starts a block comment.  The comment ends with the next occurrence of the sequence *) that is not in a conventional comment.  Within a block comment, it is illegal for the sequence (* to appear except in a conventional comment.  A character sequence is "in a conventional comment" if it occurs anywhere between the sequence -- and the nearest subsequent end-of-line character.


To see what happens in today's finest development equipment,
feed this:

#include <stdio.h>
int main() {
   /* ignore this:
      puts("*/");
    */
}

Or this, with nesting "supported":

(defun main ()
   #| ignore this
   (write "#|")
    |#)

http://www.lispworks.com/documentation/HyperSpec/Body/02_dhsa.htm

Or try OCaml for something that seems to work.
The language manages without single line comments, though.
F# adds them.

Re: Is there a way to do large block of source code comments

[robin.vowels]

On Wednesday, September 3, 2014 10:50:53 AM UTC+10, Adam Beneschan wrote:
> On Tuesday, September 2, 2014 5:07:56 PM UTC-7, robin....@gmail.com wrote:
> 
> 
> 
> > > No, this was explicitly omitted. See the Ada-83 Rationale 2.1: "Single comments
> 
> > > that are larger than one line are not provided. Such comments would require a
> 
> > > closing comment delimiter and this would again raise the dangers associated with
> 
> > > the (unintentional) omission of the closing delimiter: entire sections of a
> 
> > > program could be ignored by the compiler without the programmer realizing it, so
> 
> > > that the program would not mean what he thinks. Long comments can be written as
> 
> > > a succession of single line comments, thus combining elegance with safety."
> 
> 
> 
> > When a block of code is to be omitted (temporarily or semi-permanently)
> 
> > it's convenient to have something like /* and */ as comment markers.
> 
> > 
> 
> > It's also convenient to have comment markers for long blocks of comments.
> 
> > 
> 
> > Live parsing editors are useful tools, because they highlight
> 
> > code segments (including comments).
> 
> > 
> 
> > The above quotation is mere hype, like the author's justification for omitting
> 
> > exponentiation in Pascal, somehow more convenient to use log and exp instead!
> 
> 
> 
> No, the quotation was not hype.

Certainly was hype. And Pascal came out well before Ada did.

>  The problems caused by missing end-comment delimiters were real.
 
Really?
 
> If you're thinking that this shouldn't be a problem because of "live parsing
> editors", you're right--in 2014.

They were around from at least by the 1990s.

>  But the document that you claim contains "mere hype"
> is the Ada 83 Rationale, which came out in (drum roll) 1983.
> (Or perhaps a bit later, but the rationales weren't rationalizations
> created after the fact.)  Ada's development started several years before
> that.  The IBM PC came out in 1981, and it would have been some time before
> GUI editors were available (Eclipse was first released on 2001).
>  Before the PC, the video systems that programmers had available for
> developing programs would have been monochrome terminals with one font
> (but perhaps with some bold-face and reverse-video capabilities)
> and no graphics.  The screen-oriented editors I remember using for Pascal
> programming did not have any awareness of program syntax,
> like today's tools do.

Re: Is there a way to do large block of source code comments

[robin.vowels]

On Thursday, September 4, 2014 1:32:21 AM UTC+10, Shark8 wrote:
> On 02-Sep-14 18:07, r.nospam@gmail.com wrote:
> 
> >> No, this was explicitly omitted. See the Ada-83 Rationale 2.1: "Single comments
> 
> >> >that are larger than one line are not provided. Such comments would require a
> 
> >> >closing comment delimiter and this would again raise the dangers associated with
> 
> >> >the (unintentional) omission of the closing delimiter: entire sections of a
> 
> >> >program could be ignored by the compiler without the programmer realizing it, so
> 
> >> >that the program would not mean what he thinks. Long comments can be written as
> 
> >> >a succession of single line comments, thus combining elegance with safety."
> 
> >
> 
> > The above quotation is mere hype, like the author's justification for omitting
> 
> > exponentiation in Pascal, somehow more convenient to use log and exp instead!
>
> No, the above is a quotation from the Ada Rationale.

But it's still hype.

> It says that only single-line comments terminated by the end of the line
> were chosen so that there was no way that closing a multiline comment
> could be forgotten. Period.
>
> > Live parsing editors are useful tools, because they highlight
> > code segments (including comments).
>
> What has this got to do with *anything* WRT comments?

Um, comments highlighted in a different color from the code
make it clear which is commented.

Re: Is there a way to do large block of source code comments

[Pascal Obry]

And at the end, what we would gain?

Editor todays have hot-keys to just comment or uncomment a block by
filling or removing the "--". Why trying to fix something that is not
broken?

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://v2p.fr.eu.org
  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Is there a way to do large block of source code comments

[Georg Bauhaus]

On 04.09.14 04:37, robin.vowels@gmail.com wrote:
> Um, comments highlighted in a different color from the code
> make it clear which is commented.

But highlighting doesn't make it clear what the "commented" text
is about, and how it is structured.  Since the text is still there,
the current reader (human debugger, reviewer, successor) frequently
needs to understand it. (*)

Using comment indicators for disabling some source text is
the original sin.

However, since the practice of "quickly disabling" a part of
the source text during coding is commonplace, languages could
as well start supporting that! Specifically support that, I mean,
not via generic comments. It needs to be the language, because the
tools would have to be at least as good as the compiler and its
error handling code. But current tools tend not to be language
specific.

Another technique that may do during coding, provided that there
are no far reaching declarations that will vanish:

   if False then
      as_if (commented);
      here_as (well);
   end if;

The effect on a future reader will be just as annoying as a
"commented multiline section" of code. Fans of editors may
use folding to hide either from sight.

__
(*) With luck, an equipment actually supports a programming language,
in full, even in the presence of grammars like Ada's and in the presence
of syntax errors. Most don't, for example, the fail when ''' is not
paired, or when comment delimiters are part of strings.

Re: Is there a way to do large block of source code comments

[robin.vowels]

On Thursday, September 4, 2014 5:20:49 PM UTC+10, Georg Bauhaus wrote:
> On 04.09.14 04:37, r.nospam@gmail.com wrote:
> 
> > Um, comments highlighted in a different color from the code
> 
> > make it clear which is commented.
> 
> 
> 
> But highlighting doesn't make it clear what the "commented" text
> is about,

Just read the comment.

> and how it is structured.  Since the text is still there,

One would hope that the comment contains some text!

> the current reader (human debugger, reviewer, successor) frequently
> needs to understand it. (*)

Knowledge of English would help.

> Using comment indicators for disabling some source text is 
> the original sin.
>
> However, since the practice of "quickly disabling" a part of
> the source text during coding is commonplace,

And, I might add, during program testing, and in finding bugs in the compiler.

> languages could
> as well start supporting that! Specifically support that, I mean,
> not via generic comments. It needs to be the language, because the
> tools would have to be at least as good as the compiler and its
> error handling code. But current tools tend not to be language
> specific.
>
> Another technique that may do during coding, provided that there
> are no far reaching declarations that will vanish:
>
>    if False then
>       as_if (commented);
>       here_as (well);
>    end if;
> 
> The effect on a future reader will be just as annoying as a
> "commented multiline section" of code. Fans of editors may
> use folding to hide either from sight.

Re: Is there a way to do large block of source code comments

[Adam Beneschan]

On Wednesday, September 3, 2014 7:30:37 PM UTC-7, robin....@gmail.com wrote:

> > No, the quotation was not hype.
> 
> Certainly was hype. And Pascal came out well before Ada did.
> 
> >  The problems caused by missing end-comment delimiters were real.
> 
> Really?

Yes, really.  I have been programming for 37 years and have run into those problems.  I haven't always had IDE's to help me.
  
 
> > If you're thinking that this shouldn't be a problem because of "live parsing 
> > editors", you're right--in 2014.
> 
> They were around from at least by the 1990s.

Which still proves my point.  I'm having trouble understanding why you're still arguing this, unless you perhaps have a different definition of the term "hype" than the rest of us do.  "Hype" isn't simply anything that's not true.  It refers to something that was said with the intent to deceive or exaggerate.  And you claimed that the statement in the Rationale, about the dangers posed by omitting a closing delimiter, was "hype", which means you're claiming that the person who wrote it, in the early 1980's, was exaggerating.  And you are basing this on the fact that we have "live parsing editors" which can show you which text is comments--editors which you say came out by the 1990's, AFTER THE QUOTE WAS WRITTEN.  Isn't it reasonable to suppose that before those editors came out, the dangers were real?  And in my experience, they are real because they have happened, when one of those editors was not or is not available.

So far, you have failed to make sense, but perhaps you could help us understand what you're saying if you explain it better.  (And I normally don't get this worked up, but by calling a quote "hype" you have impugned the quote's author unjustly, and that kind of thing gets me a little riled.)

                               -- Adam

Re: Is there a way to do large block of source code comments

[G.B.]

On 04.09.14 14:46, robin.vowels@gmail.com wrote:
> On Thursday, September 4, 2014 5:20:49 PM UTC+10, Georg Bauhaus wrote:
>> On 04.09.14 04:37, r.nospam@gmail.com wrote:
>>
>>> Um, comments highlighted in a different color from the code
>>
>>> make it clear which is commented.
>>
>>
>>
>> But highlighting doesn't make it clear what the "commented" text
>> is about,
>
> Just read the comment.

It is an onerous job of a programmer to spend payed time on
guessing the reasons that some lazy (or deprived) typist
has had when turning a large part of source text into a
"comment". More guesswork for both the IDE and the compiler,
in the presence of the usual pitfalls of multiline comment
indicators, will not help.  But, since you were switching use
cases ...

>> the current reader (human debugger, reviewer, successor) frequently
>> needs to understand it. (*)
>
> Knowledge of English would help.

... to natural language comments... Why was having YX ...PROSE
... YX technically superior for writing natural language comments?

>> Using comment indicators for disabling some source text is
>> the original sin.
>>
>> However, since the practice of "quickly disabling" a part of
>> the source text during coding is commonplace,
>
> And, I might add, during program testing, and in finding bugs in the compiler.

Oh. Now back to use case "disabled source text"... Where you
said that XY ... XY is convenient. Not for the team, as outlined.


I'd agree that "elegance" is subjective and makes the Rationale
sound like marketing jargon in "combining elegance with safety"
when addressing rather primitive aspects of comment syntax.
That still does not invalidate its technical arguments.

Re: Is there a way to do large block of source code comments

[Keith Thompson]

Stefan.Lucks@uni-weimar.de writes:
[...]
> Now, I actually think it would have been possible to have block
> comments the Ada way (and is still possible for Ada 202X): Allow block
> comments (I'd suggest Pascal's "(*" and "*)" for their brackets but
> that is a matter of taste). Just prohibit nesting! I.e., any "(*"
> inside a block comment is a syntax error. Conventional "--" comments
> are allowed, and any "(*" and "*)" inside a conventional comment are
> allowed and ignored (i.e., not treated as block comment brackets).
>
> This language feature would allow to easily comment out large program
> parts without safety issues. But I doubt there is actually much demand
> for that in the Ada community!

It adds safety at the cost of not being able to "comment out" blocks of
code that already contain "(*"-style comments.

With the existing syntax, you can easily comment out a block of
text by inserting "--" at the beginning of each line, even if
that block already contains either ordinary comments or previously
commented-out code.  Most editors can do this with a few keystrokes.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Re: Is there a way to do large block of source code comments

[Shark8]

On 9/3/2014 7:37 PM, robin.vowels@gmail.com wrote:
> On Thursday, September 4, 2014 1:32:21 AM UTC+10, Shark8 wrote:
>> On 02-Sep-14 18:07, r.nospam@gmail.com wrote:
>>
>>>> No, this was explicitly omitted. See the Ada-83 Rationale 2.1: "Single comments
>>
>>>>> that are larger than one line are not provided. Such comments would require a
>>
>>>>> closing comment delimiter and this would again raise the dangers associated with
>>
>>>>> the (unintentional) omission of the closing delimiter: entire sections of a
>>
>>>>> program could be ignored by the compiler without the programmer realizing it, so
>>
>>>>> that the program would not mean what he thinks. Long comments can be written as
>>
>>>>> a succession of single line comments, thus combining elegance with safety."
>>
>>>
>>
>>> The above quotation is mere hype, like the author's justification for omitting
>>
>>> exponentiation in Pascal, somehow more convenient to use log and exp instead!
>>
>> No, the above is a quotation from the Ada Rationale.
>
> But it's still hype.


hype

verb (used with object), hyped, hyping.
1. to stimulate, excite, or agitate (usually followed by up):
2. to create interest in by flamboyant or dramatic methods; promote or 
publicize showily: a promoter who knows how to hype a prizefight.
3. to intensify (advertising, promotion, or publicity) by ingenious or 
questionable claims, methods, etc. (usually followed by up).
4. to trick; gull.

noun
5. exaggerated publicity; hoopla.
6. an ingenious or questionable claim, method, etc., used in 
advertising, promotion, or publicity to intensify the effect.
7. a swindle, deception, or trick.

-----
I really don't see how it's hype.
What definition are you using?

>> It says that only single-line comments terminated by the end of the line
>> were chosen so that there was no way that closing a multiline comment
>> could be forgotten. Period.
>>
>>> Live parsing editors are useful tools, because they highlight
>>> code segments (including comments).
>>
>> What has this got to do with *anything* WRT comments?
>
> Um, comments highlighted in a different color from the code
> make it clear which is commented.
>

So?
If that's the be-all / end-all of your editor then it's no wonder CS is 
in such a horrid state -- editors 'understanding' syntax and semantics 
well enough for syntax-highlighting is a pretty low bar.

I suggest you read up on research on things like DIANA and the R-1000 
(80's tech) which will illuminate you on just how poorly tool 
development has progressed [regressed?] over the past several decades.

Re: Is there a way to do large block of source code comments

[Randy Brukardt]

<Stefan.Lucks@uni-weimar.de> wrote in message 
news:alpine.DEB.2.11.1409032257530.28165@debian...
On Wed, 3 Sep 2014, Pascal Obry wrote:

>> Parsing a comment section???? Strange idea, I doubt this is reasonable.
>
>Hey, what do you think your Ada compiler is actually doing now? After
>"--", it searches for the line end. This *is* parsing.

Well, I'd call it lexing (it's part of the tokenizer, not the parser). But 
of course the line between lexing and parsing is rather arbitrary and 
typically depends on the implementation.

For Ada, I would say that the contents of Section 2 are lexing, and 
everything else is parsing. That was literally true in early versions of 
Janus/Ada, including pragmas [they really were dealt with lexically]). For 
Ada 95 and later, pragmas have gotten too complex and don't belong in 
Section 2, but everything else there is lexical.

Getting back to the topic, since comments are in Section 2, they are clearly 
lexical and not parsed. QED. :-) So talking about "parsing" them is 
definitely nonsense. But since the rule in question would be purely lexical, 
it certainly could have made sense.

                                           Randy.