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