www.digitalmars.com         C & C++   DMDScript  

D - {{ nested comment }}

reply "Walter" <walter digitalmars.com> writes:
I've followed all the nested/not nested comment discussions with interest. I
am reluctant to change the meaning of /* */ from C and C++.

How about a new comment style,

    {{ nested comment }}

to indicate nested comments? Is it just too lame to have three (3) different
commenting methods in D?
Jan 22 2002
next sibling parent "Juan Carlos Arevalo Baeza" <jcab roningames.com> writes:
"Walter" <walter digitalmars.com> wrote in message
news:a2kr5h$r70$2 digitaldaemon.com...
 I've followed all the nested/not nested comment discussions with interest.
I
 am reluctant to change the meaning of /* */ from C and C++.

 How about a new comment style,

     {{ nested comment }}

 to indicate nested comments? Is it just too lame to have three (3)
different
 commenting methods in D?
I wouldn't mind if you didn't, really. But if you're going to do it, try some combination of symbols that would be illegal otherwise, just in case. For example: (< ... >) [[ ... ]] (= ... =) <=| ... |=>
=> ... <=<
|> ... <| Personally, besides the beauty-looking ones, I like this one best, clearly: [[ ... ]] Salutaciones, JCAB
Jan 22 2002
prev sibling next sibling parent reply Russell Borogove <kaleja estarcion.com> writes:
Walter wrote:

 I've followed all the nested/not nested comment discussions with interest. I
 am reluctant to change the meaning of /* */ from C and C++.
 
 How about a new comment style,
 
     {{ nested comment }}
 
 to indicate nested comments? Is it just too lame to have three (3) different
 commenting methods in D?
*sob* <broken_record_mode> I can nest comments in C++ or D, as currently implemented, all day long: //brokencode// if (a == b) //brokencode// { //brokencode// DoTheThing(); // this does the thing //brokencode////oldcode// DoTheOldThing(); // we useta do this //brokencode// } Look, three layers of nested comments. </broken_record_mode> -RB
Jan 22 2002
parent reply "Robert W. Cunningham" <rwc_2001 yahoo.com> writes:
Russell Borogove wrote:

 Walter wrote:

 I've followed all the nested/not nested comment discussions with interest. I
 am reluctant to change the meaning of /* */ from C and C++.

 How about a new comment style,

     {{ nested comment }}

 to indicate nested comments? Is it just too lame to have three (3) different
 commenting methods in D?
*sob* <broken_record_mode> I can nest comments in C++ or D, as currently implemented, all day long: //brokencode// if (a == b) //brokencode// { //brokencode// DoTheThing(); // this does the thing //brokencode////oldcode// DoTheOldThing(); // we useta do this //brokencode// } Look, three layers of nested comments. </broken_record_mode> -RB
*gasp!* Struck by the obvious. You know, I do per-line commenting all the time in assembler. But we tend to use Why my brain resists doing it in block-structured languages is a mystery to me. Seriously, I just hadn't considered it. Especially when all program editors allow you to create a trivial macro to easily insert whatever you want at the start of each line (often used to rejustify a relocated block of code). Suddenly, block-structured comments, especially nested comments, make no sense to me. Why treat comments as code, or code as comments? Code is code, and comments are comments! Just because you are commenting-out some code does NOT mean your comment *is* code! It's just another comment... Think of comments as an "escape from" the language, not as "part of" the language. Now, what syntax should they have? While we're at it, I think it is high time comments had a reasonable syntax as well. They should parse! Well? Wait... Now I remember: My first programming language, FORTRAN (on punched cards, no less), reserved the first column for comment characters. Placing a "C" there would cause the compiler to drop the entire line. I think trailing comments (with an octothorp) didn't appear until FORTRAN '77 or so. And BASIC actually made comments part of the language, with the "REMARK" keyword (implemented, of course, as a PRINT to the bit-bucket). Did any other languages dedicate a keyword for comments? (Clearly, English uses parentheses for commenting.) -BobC
Jan 22 2002
parent reply "OddesE" <OddesE_XYZ hotmail.com> writes:
"Robert W. Cunningham" <rwc_2001 yahoo.com> wrote in message
news:3C4E366D.5AEEFECC yahoo.com...
 Russell Borogove wrote:

 Walter wrote:

 I've followed all the nested/not nested comment discussions with
interest. I
 am reluctant to change the meaning of /* */ from C and C++.

 How about a new comment style,

     {{ nested comment }}

 to indicate nested comments? Is it just too lame to have three (3)
different
 commenting methods in D?
*sob* <broken_record_mode> I can nest comments in C++ or D, as currently implemented, all day long: file://brokencode// if (a == b) file://brokencode// { file://brokencode// DoTheThing(); // this does the thing file://brokencode////oldcode// DoTheOldThing(); // we useta do this file://brokencode// } Look, three layers of nested comments. </broken_record_mode> -RB
*gasp!* Struck by the obvious. You know, I do per-line commenting all the time in assembler. But we tend
to use


 Why my brain resists doing it in block-structured languages is a mystery
to me.
 Seriously, I just hadn't considered it.  Especially when all program
editors
 allow you to create a trivial macro to easily insert whatever you want at
the
 start of each line (often used to rejustify a relocated block of code).

 Suddenly, block-structured comments, especially nested comments, make no
sense to
 me.  Why treat comments as code, or code as comments?  Code is code, and
comments
 are comments!  Just because you are commenting-out some code does NOT mean
your
 comment *is* code!  It's just another comment...

 Think of comments as an "escape from" the language, not as "part of" the
 language.  Now, what syntax should they have?  While we're at it, I think
it is
 high time comments had a reasonable syntax as well.  They should parse!
Well?
 Wait...  Now I remember:  My first programming language, FORTRAN (on
punched
 cards, no less), reserved the first column for comment characters.
Placing a "C"
 there would cause the compiler to drop the entire line.  I think trailing
 comments (with an octothorp) didn't appear until FORTRAN '77 or so.

 And BASIC actually made comments part of the language, with the "REMARK"
keyword
 (implemented, of course, as a PRINT to the bit-bucket).  Did any other
languages
 dedicate a keyword for comments?

 (Clearly, English uses parentheses for commenting.)


 -BobC
What I don't understand is that some of you defend non-nesting comments so fiercefully. When discussing nesting comments, the reasons for not having them usually boil down to two things: 1) You don't need them 2) It is not standard As to 1), If I really wouldn't need them, why am I asking for them? At school I learned that as a software developer I shouldn't tell users of a program just "You don't need that", without explaining very carefully why you don't need it and why it would be a problem to include the feature. Just because *you* think a certain feature is unnecessary, doesn't mean they share your opinion. If this holds true for programs, why shouldn't it hold true for languages? As to 2), you're right, but there are a *lot* of non-standard features in D, so adding (a very usable) one more to it wouldn't hurt that much :) I just don't see what the big problem with nested comments is. Please explain that to me. Would some things go terribly wrong, or be very diffcult? -- Stijn OddesE_XYZ hotmail.com http://OddesE.cjb.net __________________________________________ Remove _XYZ from my address when replying by mail giving some damn good reasons as why including the features of
Jan 23 2002
next sibling parent reply "Juan Carlos Arevalo Baeza" <jcab roningames.com> writes:
"OddesE" <OddesE_XYZ hotmail.com> wrote in message
news:a2n531$2dm0$1 digitaldaemon.com...
 What I don't understand is that some of you defend non-nesting
 comments so fiercefully.
 When discussing nesting comments, the reasons for not having
 them usually boil down to two things:

 1) You don't need them
 2) It is not standard

 I just don't see what the big problem with nested comments is.
 Please explain that to me. Would some things go terribly
 wrong, or be very diffcult?
Well... don't generalize. I, for one, already posted a positive and constructive reason to have non-nesting comments (the /* /*/ //*/ trick). 1), as you well say, is not a good reason. You can definitely use nesting comments to good effect or removing pieces of code. There are alternatives, though, which is what people are saying. Is there anything you use nesting comments for, that would not work with alternatives? The two main alternatives are: use multiple single-line comments like we do in Assembler or in makefiles (most editors can insert/remove such things using macros and such), and use a language-construct like "version() {}" to remove unwanted pieces of code without deleting them. 2) is completely bogus, IMHO. It might not be C or C++ standard, but only Walter can say wether it is or not D standard. Salutaciones, JCAB
Jan 23 2002
parent reply "OddesE" <OddesE_XYZ hotmail.com> writes:
"Juan Carlos Arevalo Baeza" <jcab roningames.com> wrote in message
news:a2n6cc$2g2n$1 digitaldaemon.com...
 "OddesE" <OddesE_XYZ hotmail.com> wrote in message
 news:a2n531$2dm0$1 digitaldaemon.com...
 What I don't understand is that some of you defend non-nesting
 comments so fiercefully.
 When discussing nesting comments, the reasons for not having
 them usually boil down to two things:

 1) You don't need them
 2) It is not standard

 I just don't see what the big problem with nested comments is.
 Please explain that to me. Would some things go terribly
 wrong, or be very diffcult?
Well... don't generalize. I, for one, already posted a positive and constructive reason to have non-nesting comments (the /* /*/ file://*/
trick).
    1), as you well say, is not a good reason. You can definitely use
nesting
 comments to good effect or removing pieces of code. There are
alternatives,
 though, which is what people are saying. Is there anything you use nesting
 comments for, that would not work with alternatives? The two main
 alternatives are: use multiple single-line comments like we do in
Assembler
 or in makefiles (most editors can insert/remove such things using macros
and
 such), and use a language-construct like "version() {}" to remove unwanted
 pieces of code without deleting them.

    2) is completely bogus, IMHO. It might not be C or C++ standard, but
only
 Walter can say wether it is or not D standard.

 Salutaciones,
                          JCAB
I agree that your trick is a valid reason for non nesting comments, but I think what you are doing when you use that trick, is actually something that the version() construct is ideal for! Commenting out code using version() on the other hand seems to me as a hack-like solution. Anyway, I was sure I was going to get flamed when I posted the previous message, but it is very refreshing to see that I was not. Thanks! (It seems to me there is *very* little flaming and trolling going on on news.digitalmars.com\D. Some newsgroups I have been to (comp.lang.c++) contain a lot of flaming. I'm really happy that none of that is going on here. Sometimes I just didn't dare to speak my mind there. Thanks everyone!) -- Stijn OddesE_XYZ hotmail.com http://OddesE.cjb.net __________________________________________ Remove _XYZ from my address when replying by mail
Jan 23 2002
parent reply "Juan Carlos Arevalo Baeza" <jcab roningames.com> writes:
"OddesE" <OddesE_XYZ hotmail.com> wrote in message
news:a2nc88$2kbr$1 digitaldaemon.com...

 Anyway, I was sure I was going to get flamed when I posted the
 previous message, but it is very refreshing to see that I was not.
 Thanks!
You're welcome.
 (It seems to me there is *very* little flaming and trolling going
 on on news.digitalmars.com\D. Some newsgroups I have been
 to (comp.lang.c++) contain a lot of flaming. I'm really happy
 that none of that is going on here. Sometimes I just didn't dare
 to speak my mind there. Thanks everyone!)
This is probably because the whole purpose of the newsgroup is to help in the design and development of this new language, which nobody has quite "learned" yet. We don't have all that many religious beliefs about the language proper to ignite the flames. I hope I'm making sense here :) Salutaciones, JCAB
Jan 23 2002
parent "Walter" <walter digitalmars.com> writes:
"Juan Carlos Arevalo Baeza" <jcab roningames.com> wrote in message
news:a2nctu$2krk$1 digitaldaemon.com...
 "OddesE" <OddesE_XYZ hotmail.com> wrote in message
 news:a2nc88$2kbr$1 digitaldaemon.com...

 Anyway, I was sure I was going to get flamed when I posted the
 previous message, but it is very refreshing to see that I was not.
 Thanks!
You're welcome.
 (It seems to me there is *very* little flaming and trolling going
 on on news.digitalmars.com\D. Some newsgroups I have been
 to (comp.lang.c++) contain a lot of flaming. I'm really happy
 that none of that is going on here. Sometimes I just didn't dare
 to speak my mind there. Thanks everyone!)
This is probably because the whole purpose of the newsgroup is to help
in
 the design and development of this new language, which nobody has quite
 "learned" yet. We don't have all that many religious beliefs about the
 language proper to ignite the flames. I hope I'm making sense here :)
I've always found, in many years of selling compilers, that the kinds of programmers interested in Digital Mars, Zortech, etc., are a definite cut above the rest. That makes building products for you all worthwhile. -Walter
Jan 25 2002
prev sibling next sibling parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
OddesE wrote:

 What I don't understand is that some of you defend non-nesting
 comments so fiercefully.
 When discussing nesting comments, the reasons for not having
 them usually boil down to two things:

 1) You don't need them
 2) It is not standard
My reason for not liking nesting comments is that it makes it non-obvious what code is active and what is not. If I see a */ I tend to think, "end of comment", not "end of nested block". That's why I like the /{ }/ syntax, as it really looks like a block, and I'm used to blocks being inside of blocks. My 2 cents :) -- The Villagers are Online! villagersonline.com .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ] .[ (a version.of(English).(precise.more)) is(possible) ] ?[ you want.to(help(develop(it))) ]
Jan 23 2002
prev sibling parent reply Russell Borogove <kaleja estarcion.com> writes:
OddesE wrote:

 What I don't understand is that some of you defend non-nesting
 comments so fiercefully.
 When discussing nesting comments, the reasons for not having
 them usually boil down to two things:
 
 1) You don't need them
 2) It is not standard
My whole point was, at the line level, we _do_ have nesting comments. Does anyone need nesting comments at the character/token level? -Russell B
Jan 23 2002
next sibling parent "OddesE" <OddesE_XYZ hotmail.com> writes:
"Russell Borogove" <kaleja estarcion.com> wrote in message
news:3C4F3861.8070604 estarcion.com...
 OddesE wrote:

 What I don't understand is that some of you defend non-nesting
 comments so fiercefully.
 When discussing nesting comments, the reasons for not having
 them usually boil down to two things:

 1) You don't need them
 2) It is not standard
My whole point was, at the line level, we _do_ have nesting comments. Does anyone need nesting comments at the character/token level? -Russell B
Yes, I do! :) But in the end it all depends on how you define 'need'. I know I would really like them. -- Stijn OddesE_XYZ hotmail.com http://OddesE.cjb.net __________________________________________ Remove _XYZ from my address when replying by mail
Jan 24 2002
prev sibling parent reply "D" <s_nudds hotmail.com> writes:
Yes to comment out blocks of code without having to put a "/" at the
beginning of each line.


Russell Borogove <kaleja estarcion.com> wrote in message
 My whole point was, at the line level, we _do_ have

 nesting comments. Does anyone need nesting comments
 at the character/token level?
Feb 04 2002
parent "D" <s_nudds hotmail.com> writes:
Sorry, I should have said that block comments that nest are required.  They
are not required at the character/token level.  Just at the line level.

D <s_nudds hotmail.com> wrote in message
news:a3nmsv$2bdi$1 digitaldaemon.com...
 Yes to comment out blocks of code without having to put a "/" at the
 beginning of each line.


 Russell Borogove <kaleja estarcion.com> wrote in message
 My whole point was, at the line level, we _do_ have

 nesting comments. Does anyone need nesting comments
 at the character/token level?
Feb 05 2002
prev sibling next sibling parent reply "Mike Wynn" <mike.wynn l8night.co.uk> writes:
Have you considered looking for <HTML> at the begining of every source file
in fact < appears as the first non white space char, then the chances are
that its D inside HTML. so a program can begin <code>
if you then removed <SPAN> (nested) areas from within the <code> sections
you get have nestable comments without changing the syntax of D

or use <span> </span>
always as nestable comment always

or to veiw comments with a bit of logic ...
/* */  original c comments
//       one line c++ comments
why not continue the trend
/{   }/  nestable D comments

/<symbol> is comment { we all know is block/scope


"Walter" <walter digitalmars.com> wrote in message
news:a2kr5h$r70$2 digitaldaemon.com...
 I've followed all the nested/not nested comment discussions with interest.
I
 am reluctant to change the meaning of /* */ from C and C++.

 How about a new comment style,

     {{ nested comment }}

 to indicate nested comments? Is it just too lame to have three (3)
different
 commenting methods in D?
Mike.
Jan 22 2002
next sibling parent reply "Rajiv Bhagwat" <dataflow vsnl.com> writes:
I have seen the //brokencode// style comments further in this thread, even
then, inserting a smaller 'commenter' just at the start and at the end feels
better.

Similar to clip/clipprep style, I suggest,
/a{ ........  /a}
Where 'a' could be any single digit or number. This will allow true nesting
of comments, say like:

/a{
part1 of the code
    /b{
    part2 of the code
    /b}
part3 of the code
/a}

Of course, you can adopt "//a{" to deviate little from the usual // style
comments.
- Rajiv

"Mike Wynn" <mike.wynn l8night.co.uk> wrote in message
news:a2kvgk$tka$1 digitaldaemon.com...
 Have you considered looking for <HTML> at the begining of every source
file
 in fact < appears as the first non white space char, then the chances are
 that its D inside HTML. so a program can begin <code>
 if you then removed <SPAN> (nested) areas from within the <code> sections
 you get have nestable comments without changing the syntax of D

 or use <span> </span>
 always as nestable comment always

 or to veiw comments with a bit of logic ...
 /* */  original c comments
 //       one line c++ comments
 why not continue the trend
 /{   }/  nestable D comments

 /<symbol> is comment { we all know is block/scope


 "Walter" <walter digitalmars.com> wrote in message
 news:a2kr5h$r70$2 digitaldaemon.com...
 I've followed all the nested/not nested comment discussions with
interest.
 I
 am reluctant to change the meaning of /* */ from C and C++.

 How about a new comment style,

     {{ nested comment }}

 to indicate nested comments? Is it just too lame to have three (3)
different
 commenting methods in D?
Mike.
Jan 22 2002
parent "OddesE" <OddesE_XYZ hotmail.com> writes:
"Rajiv Bhagwat" <dataflow vsnl.com> wrote in message
news:a2lls2$1chf$1 digitaldaemon.com...
 I have seen the file://brokencode// style comments further in this thread,
even
 then, inserting a smaller 'commenter' just at the start and at the end
feels
 better.

 Similar to clip/clipprep style, I suggest,
 /a{ ........  /a}
 Where 'a' could be any single digit or number. This will allow true
nesting
 of comments, say like:

 /a{
 part1 of the code
     /b{
     part2 of the code
     /b}
 part3 of the code
 /a}

 Of course, you can adopt "//a{" to deviate little from the usual // style
 comments.
 - Rajiv
No, I don't like it. Matching up the correct characters is just a drag and totally unnecesary. "//a" doesn't seem logical to me because // signals a single line comment, not a block. -- Stijn OddesE_XYZ hotmail.com http://OddesE.cjb.net __________________________________________ Remove _XYZ from my address when replying by mail
Jan 23 2002
prev sibling next sibling parent "Sean L. Palmer" <spalmer iname.com> writes:
I actually really like this idea... /{ }/ sends a clear message that a
comment "scope" is being introduced and then closed.  It's not legal
anywhere else.  And it fits well with the other comments, similar, but just
different enough to not be confusing.  I don't know that the matching
identifiers the other replier suggested are necessary, but I think some
rules about whether  something like this is legal should be devised:

/{

/* /}  */

does the  /} even get parsed, since it's inside some other comment?  My
guess is that the above would have to be flagged as an error.

Sean

"Mike Wynn" <mike.wynn l8night.co.uk> wrote in message
news:a2kvgk$tka$1 digitaldaemon.com...
 Have you considered looking for <HTML> at the begining of every source
file
 in fact < appears as the first non white space char, then the chances are
 that its D inside HTML. so a program can begin <code>
 if you then removed <SPAN> (nested) areas from within the <code> sections
 you get have nestable comments without changing the syntax of D

 or use <span> </span>
 always as nestable comment always

 or to veiw comments with a bit of logic ...
 /* */  original c comments
 //       one line c++ comments
 why not continue the trend
 /{   }/  nestable D comments

 /<symbol> is comment { we all know is block/scope


 "Walter" <walter digitalmars.com> wrote in message
 news:a2kr5h$r70$2 digitaldaemon.com...
 I've followed all the nested/not nested comment discussions with
interest.
 I
 am reluctant to change the meaning of /* */ from C and C++.

 How about a new comment style,

     {{ nested comment }}

 to indicate nested comments? Is it just too lame to have three (3)
different
 commenting methods in D?
Mike.
Jan 23 2002
prev sibling next sibling parent "OddesE" <OddesE_XYZ hotmail.com> writes:
"Mike Wynn" <mike.wynn l8night.co.uk> wrote in message
news:a2kvgk$tka$1 digitaldaemon.com...
<SNIP>
 or to veiw comments with a bit of logic ...
 /* */  original c comments
 //       one line c++ comments
 why not continue the trend
 /{   }/  nestable D comments

 /<symbol> is comment { we all know is block/scope
<SNIP>
 Mike.
YES! Agreed! I think this is definitely a good soulution! / Signals a comment, { Signals a nestable block, so /{ Signals a nestable comment. I would be very happy with this solution. -- Stijn OddesE_XYZ hotmail.com http://OddesE.cjb.net __________________________________________ Remove _XYZ from my address when replying by mail
Jan 23 2002
prev sibling next sibling parent reply nik <nik nospam.org> writes:
Mike Wynn wrote:

 Have you considered looking for <HTML> at the begining of every source file
 in fact < appears as the first non white space char, then the chances are
 that its D inside HTML. so a program can begin <code>
 if you then removed <SPAN> (nested) areas from within the <code> sections
 you get have nestable comments without changing the syntax of D
 
 or use <span> </span>
 always as nestable comment always
 
 or to veiw comments with a bit of logic ...
 /* */  original c comments
 //       one line c++ comments
 why not continue the trend
 /{   }/  nestable D comments
 
 /<symbol> is comment { we all know is block/scope
 
 
 "Walter" <walter digitalmars.com> wrote in message
 news:a2kr5h$r70$2 digitaldaemon.com...
 
I've followed all the nested/not nested comment discussions with interest.
I
am reluctant to change the meaning of /* */ from C and C++.

How about a new comment style,

    {{ nested comment }}

to indicate nested comments? Is it just too lame to have three (3)
different
commenting methods in D?
Mike.
I think the documentation comment syntax died or is hibernating and waiting for d/XML discussion to "finalise". My suggestion for documentation comments is that we have, // - single line comment /* - multi line comment /{ - nested comments ergo, / - documentation comment (taken from javadoc blah syntax) Yeah, one more comment type for d. As far as compiler is concerned /* and / are at the same level, and /{ would nest all the comment types. g'bye, - nik.
Jan 23 2002
parent "OddesE" <OddesE_XYZ hotmail.com> writes:
"nik" <nik nospam.org> wrote in message news:3C4F2489.1010507 nospam.org...
 Mike Wynn wrote:

 Have you considered looking for <HTML> at the begining of every source
file
 in fact < appears as the first non white space char, then the chances
are
 that its D inside HTML. so a program can begin <code>
 if you then removed <SPAN> (nested) areas from within the <code>
sections
 you get have nestable comments without changing the syntax of D

 or use <span> </span>
 always as nestable comment always

 or to veiw comments with a bit of logic ...
 /* */  original c comments
 //       one line c++ comments
 why not continue the trend
 /{   }/  nestable D comments

 /<symbol> is comment { we all know is block/scope


 "Walter" <walter digitalmars.com> wrote in message
 news:a2kr5h$r70$2 digitaldaemon.com...

I've followed all the nested/not nested comment discussions with
interest.

 I

am reluctant to change the meaning of /* */ from C and C++.

How about a new comment style,

    {{ nested comment }}

to indicate nested comments? Is it just too lame to have three (3)
different
commenting methods in D?
Mike.
I think the documentation comment syntax died or is hibernating and waiting for d/XML discussion to "finalise". My suggestion for documentation comments is that we have, // - single line comment /* - multi line comment /{ - nested comments ergo, / - documentation comment (taken from javadoc blah syntax) Yeah, one more comment type for d. As far as compiler is concerned /* and / are at the same level, and /{ would nest all the comment types. g'bye, - nik.
Agreed, except that Walter seems to want to keep ' ' reserved... :) I kinda liked my /*doc ... doc*/ syntax, but maybe it is to verbatim? -- Stijn OddesE_XYZ hotmail.com http://OddesE.cjb.net __________________________________________ Remove _XYZ from my address when replying by mail
Jan 23 2002
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Mike Wynn" <mike.wynn l8night.co.uk> wrote in message
news:a2kvgk$tka$1 digitaldaemon.com...
 or to veiw comments with a bit of logic ...
 /* */  original c comments
 //       one line c++ comments
 why not continue the trend
 /{   }/  nestable D comments
Your trend idea is a good one; what I've done is do /+ +/ for nested comments. Why not /{ }/? It just didn't look right on the page. I also worried about things like: foo() { blah... }// comment the } and the / just don't go together. The /+ looks similar enough to /* to be recognizable as a comment, but different enough to not be confusing: /+ code code +/ or even: /+++++++++++++ code that doesn't work code that doesn't work +++++++++++++/ has a bit of a cachet to it. I thought of /- -/, but it wound up looking like someone trying to draw a picture instead of a comment <g>. www.digitalmars.com/d/lex.html
Jan 30 2002
next sibling parent reply "Robert W. Cunningham" <rwc_2001 yahoo.com> writes:
Walter wrote:

 Your trend idea is a good one; what I've done is do /+  +/ for nested
 comments.
 ...
     /+
         code
         code
      +/

 or even:

     /+++++++++++++
         code that doesn't work
         code that doesn't work
      +++++++++++++/
My favorite block comment looks like this: /*\ |*| My comment block. |*| \*/ When I had a "more important" comment, the above would become: /**\ |**| My function() declaration. |**| \**/ And a top-level documentation comment would be: /***\ |***| My explanation for why I did this. |***| \***/ If nesting is a problem, these can easily become: ///*\ //|*| Slashes rock. //|*| //\*/ Decades ago I wrote emacs lisp code to automate the process of adding, moving, nesting and removing this style of comment. Then I stopped using emacs and just did it manually. No hassle, really. Of course, this looks just dandy too: /++\ |++| Then again, on the plus side... |++| \++/ We just need to make sure that a back-slash in comments has no special meaning (a given in D). -BobC
Jan 30 2002
parent "Sean L. Palmer" <spalmer iname.com> writes:
I prefer my comments not to look like ASCII art.  This is no longer the
nineties.  ;)  I find syntax highlighting alone is really good enough.  I
set my comment color to grey so it looks like it's greyed out (yet still
readable).  I just wish the IDE's would catch up and allow you to specify
HTML templates to control how different kinds of things are displayed.  I
guess some tools like Together do this.

I kinda like /+ +/, but dang that's gonna be wierd to get used to typing.
;)  I'll get it though.  First time is the roughest.  heh

Thanks, Walter!

Sean

"Robert W. Cunningham" <rwc_2001 yahoo.com> wrote in message
news:3C58C0E5.2585BBF4 yahoo.com...
 My favorite block comment looks like this:

 /*\
 |*|  My comment block.
 |*|
 \*/

 When I had a "more important" comment, the above would become:

 /**\
 |**|  My function() declaration.
 |**|
 \**/

 And a top-level documentation comment would be:

 /***\
 |***|  My explanation for why I did this.
 |***|
 \***/

 If nesting is a problem, these can easily become:

 ///*\
 //|*|  Slashes rock.
 //|*|
 //\*/

 Decades ago I wrote emacs lisp code to automate the process of adding,
moving,
 nesting and removing this style of comment.  Then I stopped using emacs
and
 just did it manually.  No hassle, really.

 Of course, this looks just dandy too:

 /++\
 |++|  Then again, on the plus side...
 |++|
 \++/

 We just need to make sure that a back-slash in comments has no special
meaning
 (a given in D).


 -BobC
Jan 31 2002
prev sibling parent reply "Roberto Mariottini" <rmariottini lycosmail.com> writes:
"Walter" <walter digitalmars.com> ha scritto nel messaggio
news:a3a5nd$2a39$1 digitaldaemon.com...
 Your trend idea is a good one; what I've done is do /+  +/ for nested
 comments. Why not /{  }/? It just didn't look right on the page. I also
 worried about things like:

     foo() { blah... }// comment

 the } and the / just don't go together. The /+ looks similar enough to /*
to
 be recognizable as a comment, but different enough to not be confusing:

     /+
         code
         code
      +/

 or even:

     /+++++++++++++
         code that doesn't work
         code that doesn't work
      +++++++++++++/

 has a bit of a cachet to it. I thought of /- -/, but it wound up looking
 like someone trying to draw a picture instead of a comment <g>.
please note that a = b/-c; is a valid C/C++ statement, and also a = b/+c; BTW, also *p = *q/*r; is a valid C/C++ statement... Why life is so complicated? Ciao
Jan 30 2002
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Roberto Mariottini" <rmariottini lycosmail.com> wrote in message
news:a3at25$2jjj$1 digitaldaemon.com...
 please note that  a = b/-c; is a valid C/C++ statement, and also a = b/+c;
 BTW, also *p = *q/*r; is a valid C/C++ statement...
We've already learned to live with q/*r, so I don't think that b/+c will be a problem, especially since there is no point to the + in +c.
Jan 31 2002
parent reply "Sean L. Palmer" <spalmer iname.com> writes:
This wouldn't be a problem if our keyboards had ÷ on them.  ;)



Sean


"Walter" <walter digitalmars.com> wrote in message
news:a3avoq$2m8s$1 digitaldaemon.com...
 "Roberto Mariottini" <rmariottini lycosmail.com> wrote in message
 news:a3at25$2jjj$1 digitaldaemon.com...
 please note that  a = b/-c; is a valid C/C++ statement, and also a =
b/+c;
 BTW, also *p = *q/*r; is a valid C/C++ statement...
We've already learned to live with q/*r, so I don't think that b/+c will
be
 a problem, especially since there is no point to the + in +c.
Jan 31 2002
parent "Walter" <walter digitalmars.com> writes:


"Sean L. Palmer" <spalmer iname.com> wrote in message
news:a3b1sg$2na1$1 digitaldaemon.com...
 This wouldn't be a problem if our keyboards had ÷ on them.  ;)


anymore...
 Sean


 "Walter" <walter digitalmars.com> wrote in message
 news:a3avoq$2m8s$1 digitaldaemon.com...
 "Roberto Mariottini" <rmariottini lycosmail.com> wrote in message
 news:a3at25$2jjj$1 digitaldaemon.com...
 please note that  a = b/-c; is a valid C/C++ statement, and also a =
b/+c;
 BTW, also *p = *q/*r; is a valid C/C++ statement...
We've already learned to live with q/*r, so I don't think that b/+c will
be
 a problem, especially since there is no point to the + in +c.
Jan 31 2002
prev sibling parent reply "Marc Cote" <cotemark globetrotter.net> writes:
 BTW, also *p = *q/*r; is a valid C/C++ statement...
Are you sure ? If so, then this should compile ok: main( ) { char *p,*q,*r; *p = *q/*r; } but it does not, sc t.cpp gives: t.cpp(8) : Lexical error: end of file found before end of comment, line 1 Fatal error: premature end of source file --- errorlevel 1
Jan 31 2002
next sibling parent reply "Martin York" <Martin.York veritas.com> writes:
If memory serves my write:

In C/C++
 pre-processing of the source is performed before any lexical analysis.
Since it is the pre-processor that replaces comments by white space the
following is not legal C/C++.

If my memory is faulty then I ask forgiveness.

Martin


"Marc Cote" <cotemark globetrotter.net> wrote in message
news:a3bsie$1kte$1 digitaldaemon.com...
 BTW, also *p = *q/*r; is a valid C/C++ statement...
Are you sure ? If so, then this should compile ok: main( ) { char *p,*q,*r; *p = *q/*r; } but it does not, sc t.cpp gives: t.cpp(8) : Lexical error: end of file found before end of comment, line 1 Fatal error: premature end of source file --- errorlevel 1
Jan 31 2002
parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Actually, the rule is that "tokens are parsed as the longest possible token" or
some such.  That means that while "/*" could be parsed as 2 tokens, '/' and
'*', it instead is parsed as one token.  It's part of the C standard.
Otherwise we couldn't parse the expression
    c << 2
as the "<<" might be parsed as two '<' tokens.  This led to the classic C++
template error:
    Foo<Bar<Baz>>
which had to be re-written as:
    Foo<Bar<Baz> >
to avoid confusing the compiler.

In C, you must use spaces to separate some combinations of operators.  I think
that what Walter meant was that the expression is "conceptually right", but, as
you found out, it is a syntax error.

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]
Jan 31 2002
prev sibling parent "Mike Wynn" <mike.wynn l8night.co.uk> writes:
I thought of the comment about is being a valid stament was to point out
that ' *p      /       *r' is valid
and *p/*r looks the same but is in fact *p/<comment-start>
and that's been there for years, and no one complained.
so just 'cos /+s is valid does not full discount /+ +/ as nested comment

or is it just that a very similar example was in the pclint advert in
DrDobbs last year

"Marc Cote" <cotemark globetrotter.net> wrote in message
news:a3bsie$1kte$1 digitaldaemon.com...
 BTW, also *p = *q/*r; is a valid C/C++ statement...
Are you sure ? If so, then this should compile ok: main( ) { char *p,*q,*r; *p = *q/*r; } but it does not, sc t.cpp gives: t.cpp(8) : Lexical error: end of file found before end of comment, line 1 Fatal error: premature end of source file --- errorlevel 1
Jan 31 2002
prev sibling parent "D" <s_nudds hotmail.com> writes:
New commenting styles are not needed.   Simply make /**/ nestable.  There is
no valid reason not to.

There are arguments, but no valid reasons.

That comments are not nestable in C is one of C's large number of mindless
characteristics.

May K&R burn eternally in hell.

Walter <walter digitalmars.com> wrote in message
news:a2kr5h$r70$2 digitaldaemon.com...
 I've followed all the nested/not nested comment discussions with interest.
I
 am reluctant to change the meaning of /* */ from C and C++.

 How about a new comment style,

     {{ nested comment }}

 to indicate nested comments? Is it just too lame to have three (3)
different
 commenting methods in D?
Feb 04 2002