www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - a new type of comment - [suggestion] - disincluded code

reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
I would like to suggest a new way of commenting out code, or more accurately,
marking a block of code to not get compiled.

Okay, so D already has 3 types of comments
and most people reading this are probably wondering at this point
how I could possibly even think of suggesting yet another...
especially since there are much more pressing matters at hand.

Well, what I have in mind is a way to take advantage of the lexical structure
of the D language to make debugging easier and more efficient.

Right now, our choices for commenting are...
1: A pair of characters that placed together on a line keep the rest of that
line from getting compiled.
2: Two pairs of characters that placed at opposite ends of a block of text will
keep that text from getting compiled.
3: Two pairs of characters that placed at opposite ends of a block of code
(including comments) will keep that code from getting compiled.

I propose the following additional specification for a non-compiling block..
4. A character (or group of characters) that when placed
 directly after the "{" at the beginning of a compound statement block will
cause
 that statement block to be treated by the compiler as if it were empty.

For example, if "[/]" were used as for this purpose, then....
if (true) {[/]writef(`test %s`,st); a += b;}
would compile as...
if (true) {}

I'm not sure what character or group of characters would be best for this
purpose,
but it would be best if a single character could be used that never occurs
after "{" for any other reason,
and could be easily spoted and recognized .

This would allow quick disincluding of an entire logical block of code with a
simple modification,
and would not require an end marker, since the matching close brace "}" would
mark the end of the disincluded block.

This type of debug tagging would disable a block of code (and all sub-blocks
contained within that block)
quickly and neatly, without having to locate and mark both ends of the block...
since the compiler would take care of finding the other end.

Also, editors designed to check syntx could still syntax check within such a
block,
even though it's not going to be compiled,
since it would be considered "disincluded code",
rather than simply "comment text".

Anyone have a suggestion for what character to use?
I don't expect this idea to get included into the D language any time soon,
but I'm hoping that if we can open a reasonable discussion of it,
perhaps it would be considered for inclusion some day.

TechnoZeus
May 18 2005
next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
Cool idea. Comments which are "part of the code" rather than "part of the  
text" so to speak. As in, they are affected by the structure of the code,  
not outside the structure of the code.

Would:

if (a) {/
   ..etc..
}

cause 'a' to be evaluated or not? It would be better (IMO) if the answer  
is "no".

Regan

On Wed, 18 May 2005 21:16:18 -0500, TechnoZeus <TechnoZeus PeoplePC.com>  
wrote:

 I would like to suggest a new way of commenting out code, or more  
 accurately, marking a block of code to not get compiled.

 Okay, so D already has 3 types of comments
 and most people reading this are probably wondering at this point
 how I could possibly even think of suggesting yet another...
 especially since there are much more pressing matters at hand.

 Well, what I have in mind is a way to take advantage of the lexical  
 structure of the D language to make debugging easier and more efficient.

 Right now, our choices for commenting are...
 1: A pair of characters that placed together on a line keep the rest of  
 that line from getting compiled.
 2: Two pairs of characters that placed at opposite ends of a block of  
 text will keep that text from getting compiled.
 3: Two pairs of characters that placed at opposite ends of a block of  
 code (including comments) will keep that code from getting compiled.

 I propose the following additional specification for a non-compiling  
 block..
 4. A character (or group of characters) that when placed
  directly after the "{" at the beginning of a compound statement block  
 will cause
  that statement block to be treated by the compiler as if it were empty.

 For example, if "[/]" were used as for this purpose, then....
 if (true) {[/]writef(`test %s`,st); a += b;}
 would compile as...
 if (true) {}

 I'm not sure what character or group of characters would be best for  
 this purpose,
 but it would be best if a single character could be used that never  
 occurs after "{" for any other reason,
 and could be easily spoted and recognized .

 This would allow quick disincluding of an entire logical block of code  
 with a simple modification,
 and would not require an end marker, since the matching close brace "}"  
 would mark the end of the disincluded block.

 This type of debug tagging would disable a block of code (and all  
 sub-blocks contained within that block)
 quickly and neatly, without having to locate and mark both ends of the  
 block...
 since the compiler would take care of finding the other end.

 Also, editors designed to check syntx could still syntax check within  
 such a block,
 even though it's not going to be compiled,
 since it would be considered "disincluded code",
 rather than simply "comment text".

 Anyone have a suggestion for what character to use?
 I don't expect this idea to get included into the D language any time  
 soon,
 but I'm hoping that if we can open a reasonable discussion of it,
 perhaps it would be considered for inclusion some day.

 TechnoZeus
May 18 2005
next sibling parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opsqz6f6h323k2f5 nrage.netwin.co.nz...

 Cool idea. Comments which are "part of the code" rather than "part of the
 text" so to speak. As in, they are affected by the structure of the code,
 not outside the structure of the code.

 Would:

 if (a) {/
    ..etc..
 }

 cause 'a' to be evaluated or not? It would be better (IMO) if the answer
 is "no".

 Regan

 On Wed, 18 May 2005 21:16:18 -0500, TechnoZeus <TechnoZeus PeoplePC.com>
 wrote:

 I would like to suggest a new way of commenting out code, or more
 accurately, marking a block of code to not get compiled.

 Okay, so D already has 3 types of comments
 and most people reading this are probably wondering at this point
 how I could possibly even think of suggesting yet another...
 especially since there are much more pressing matters at hand.

 Well, what I have in mind is a way to take advantage of the lexical
 structure of the D language to make debugging easier and more efficient.

 Right now, our choices for commenting are...
 1: A pair of characters that placed together on a line keep the rest of
 that line from getting compiled.
 2: Two pairs of characters that placed at opposite ends of a block of
 text will keep that text from getting compiled.
 3: Two pairs of characters that placed at opposite ends of a block of
 code (including comments) will keep that code from getting compiled.

 I propose the following additional specification for a non-compiling
 block..
 4. A character (or group of characters) that when placed
  directly after the "{" at the beginning of a compound statement block
 will cause
  that statement block to be treated by the compiler as if it were empty.

 For example, if "[/]" were used as for this purpose, then....
 if (true) {[/]writef(`test %s`,st); a += b;}
 would compile as...
 if (true) {}

 I'm not sure what character or group of characters would be best for
 this purpose,
 but it would be best if a single character could be used that never
 occurs after "{" for any other reason,
 and could be easily spoted and recognized .

 This would allow quick disincluding of an entire logical block of code
 with a simple modification,
 and would not require an end marker, since the matching close brace "}"
 would mark the end of the disincluded block.

 This type of debug tagging would disable a block of code (and all
 sub-blocks contained within that block)
 quickly and neatly, without having to locate and mark both ends of the
 block...
 since the compiler would take care of finding the other end.

 Also, editors designed to check syntx could still syntax check within
 such a block,
 even though it's not going to be compiled,
 since it would be considered "disincluded code",
 rather than simply "comment text".

 Anyone have a suggestion for what character to use?
 I don't expect this idea to get included into the D language any time
 soon,
 but I'm hoping that if we can open a reasonable discussion of it,
 perhaps it would be considered for inclusion some day.

 TechnoZeus




Yep.  Exactly.  There are so many times when something of that nature would
come in handy.

TZ
May 18 2005
prev sibling parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opsqz6f6h323k2f5 nrage.netwin.co.nz...

 Cool idea. Comments which are "part of the code" rather than "part of the
 text" so to speak. As in, they are affected by the structure of the code,
 not outside the structure of the code.

 Would:

 if (a) {/
    ..etc..
 }

 cause 'a' to be evaluated or not? It would be better (IMO) if the answer
 is "no".

 Regan


Oh, sorry... forgot to answer your question.  If "/" was used as the block
comment character, then
if (a) {/..etc..}
would be evaluated exactly the same as
if(a){}
as if everything inside but not including the braces had been commented out.

TZ
May 18 2005
prev sibling next sibling parent reply Jay <Jay_member pathlink.com> writes:
In article <d6gt7l$os5$1 digitaldaemon.com>, TechnoZeus says... 

I propose the


following additional specification for a non-compiling block.. 

4. A character


(or group of characters) that when placed 

 directly after the "{" at the


beginning of a compound statement block will 
cause 

 that statement block to


be treated by the compiler as if it were empty. 

 
For example, if "[/]" were


used as for this purpose, then.... 

if (true) {[/]writef(`test %s`,st); a +=


b;} 

would compile as... 
if (true) {} 
 
Anyone have a suggestion for what


character to use? 
 
I can't think of one character but I think the following
five characters can 
do it: 
 
if(0) 
 
They meet all requirements except the
one which requires them to be after the 
opening brace. 
 
Jay
May 18 2005
next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Thu, 19 May 2005 03:28:42 +0000 (UTC), Jay <Jay_member pathlink.com>  
wrote:

 I can't think of one character but I think the following
 five characters can
 do it:
 if(0)
 They meet all requirements except the
 one which requires them to be after the
 opening brace.


You have a point.. In addition a good IDE would surely be able to insert  
any of the existing comment characters to include/dis-include an entire  
block of code.

regan
May 18 2005
parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opsqz6teo123k2f5 nrage.netwin.co.nz...

 On Thu, 19 May 2005 03:28:42 +0000 (UTC), Jay <Jay_member pathlink.com>
 wrote:

 I can't think of one character but I think the following
 five characters can
 do it:
 if(0)
 They meet all requirements except the
 one which requires them to be after the
 opening brace.


 You have a point.. In addition a good IDE would surely be able to insert
 any of the existing comment characters to include/dis-include an entire
 block of code.

 regan


Have you found a good IDE for the D language
or more specifically, for creating Windows programs with the Digital Mars D
Compiler?

TZ
May 19 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Thu, 19 May 2005 15:20:50 -0500, TechnoZeus <TechnoZeus PeoplePC.com>  
wrote:

 "Regan Heath" <regan netwin.co.nz> wrote in message  
 news:opsqz6teo123k2f5 nrage.netwin.co.nz...

 On Thu, 19 May 2005 03:28:42 +0000 (UTC), Jay <Jay_member pathlink.com>
 wrote:

 I can't think of one character but I think the following
 five characters can
 do it:
 if(0)
 They meet all requirements except the
 one which requires them to be after the
 opening brace.


 You have a point.. In addition a good IDE would surely be able to insert
 any of the existing comment characters to include/dis-include an entire
 block of code.

 regan


 Have you found a good IDE for the D language
 or more specifically, for creating Windows programs with the Digital  
 Mars D Compiler?


Nope... I'm dreaming.

Regan
May 19 2005
parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opsq1vk8wu23k2f5 nrage.netwin.co.nz...

 On Thu, 19 May 2005 15:20:50 -0500, TechnoZeus <TechnoZeus PeoplePC.com>
 wrote:

 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opsqz6teo123k2f5 nrage.netwin.co.nz...

 On Thu, 19 May 2005 03:28:42 +0000 (UTC), Jay <Jay_member pathlink.com>
 wrote:

 I can't think of one character but I think the following
 five characters can
 do it:
 if(0)
 They meet all requirements except the
 one which requires them to be after the
 opening brace.


 You have a point.. In addition a good IDE would surely be able to insert
 any of the existing comment characters to include/dis-include an entire
 block of code.

 regan


 Have you found a good IDE for the D language
 or more specifically, for creating Windows programs with the Digital
 Mars D Compiler?


 Nope... I'm dreaming.

 Regan


Me too... but since editing text is a part of programming D,
being able to disable or enable a logical block of code by simply typing or
deleting a single character
would come in handy "in the real world".  :)

Besides, I'm pretty sure it's a feature that no other language has.
(The closest I'm aware of in existance is a single character "line comment".)
...which means, D could be the first.

TZ
May 19 2005
prev sibling parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Jay" <Jay_member pathlink.com> wrote in message
news:d6h15a$scr$1 digitaldaemon.com...

 In article <d6gt7l$os5$1 digitaldaemon.com>, TechnoZeus says...

I propose the


 following additional specification for a non-compiling block..

4. A character


 (or group of characters) that when placed

 directly after the "{" at the


 beginning of a compound statement block will
 cause

 that statement block to


 be treated by the compiler as if it were empty.

For example, if "[/]" were


 used as for this purpose, then....

if (true) {[/]writef(`test %s`,st); a +=


 b;}

would compile as...
if (true) {}

Anyone have a suggestion for what


 character to use?

 I can't think of one character but I think the following
 five characters can
 do it:

 if(0)

 They meet all requirements except the
 one which requires them to be after the
 opening brace.

 Jay


Functionally, yes... as far as I can tell.
However, I was hoping for something that could be standardized
and would allow easy searches for such disinclusions,
as well as allowing editors to assign attributes such as italic type
or a light font to the disincluded block.

I was also hoping that a single character could be used,
because it's easy to type or delete a single character quickly.
This may not seem like an important point,
but when trying to track down an elusive bug it may
make a big difference.

TZ
May 18 2005
prev sibling next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"TechnoZeus" <TechnoZeus PeoplePC.com> wrote in message
news:d6gt7l$os5$1 digitaldaemon.com...

 I propose the following additional specification for a non-compiling


block..

 4. A character (or group of characters) that when placed
  directly after the "{" at the beginning of a compound statement block


will cause

  that statement block to be treated by the compiler as if it were empty.

 For example, if "[/]" were used as for this purpose, then....
 if (true) {[/]writef(`test %s`,st); a += b;}
 would compile as...
 if (true) {}


I do this all the time, as in:

    if (condition) { ... statements ... }

I'll insert 0&&:

    if (0 && condition) { ... statements ... }
May 18 2005
parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:d6h32q$tpp$1 digitaldaemon.com...

 "TechnoZeus" <TechnoZeus PeoplePC.com> wrote in message
 news:d6gt7l$os5$1 digitaldaemon.com...

 I propose the following additional specification for a non-compiling


 block..

 4. A character (or group of characters) that when placed
  directly after the "{" at the beginning of a compound statement block


 will cause

  that statement block to be treated by the compiler as if it were empty.

 For example, if "[/]" were used as for this purpose, then....
 if (true) {[/]writef(`test %s`,st); a += b;}
 would compile as...
 if (true) {}


 I do this all the time, as in:

     if (condition) { ... statements ... }

 I'll insert 0&&:

     if (0 && condition) { ... statements ... }


Jay suggested the same thing, and at first glance I thought (and even
commented) that it was functionally the same as what I was talking about...
but after thinking about it more, I realized that it's not quite.

For example...

void main()
{
int a() if(0){return 9;}
}

//... will not compile, and in fact, neither will

void main()
{
int a() if(0){}
}

//... but

void main()
{
int a(){}
}

//... will, and so will...

void main()
{
int a() {/+return 9;+/}
}

//... which is demonstrative of the functionality I'm looking for, except that
it requires marking both ends of the block.
//... The idea is to take advantage of the fact that compound statement blocks
of code already have a beginning and end,
//... and that commenting out the contents of such a block results in a logical
empty block, which in most cases will still compile.

TZ
May 18 2005
parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
// In other words, I would like to be able to take buggy code like...

void main()
{
int a() {int a="x",b=2; return a+b;}
}

// and add one character to it such as....

void main()
{
int a() {int a="x",b=2; return a+b;}
}

// to get the functional equivilent of...

void main()
{
int a() { /+ int a="x",b=2; return a+b; +/ }
}

// for testing purposes, preferably letting the compiler still
// check the code between the braces for syntax errors,
// issuing only a warning if a syntax error is found in the disincluded code,
but not interfering with compilation
// (although systax checking of such disincluded code should be at the option
of the compiler writer)
// but letting it ignore any non-syntactical errors and
// not produce any compiled code for the text between "{/" and it's matching
"}".

This would allow logic errors to be found much more quickly.

Actually, now that I think more about it...
better to let the compiler ignore syntax errors also in the disincluded text...
since removal of a single character re-includes the text so that syntax can be
checked...
However, it would still have to tokenize the disencluded code at least enoug to
find the "matching" close brace.

TZ
May 18 2005
parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"TechnoZeus" <TechnoZeus PeoplePC.com> wrote in message
news:d6hbor$14pu$1 digitaldaemon.com...

 // In other words, I would like to be able to take buggy code like...

 void main()
 {
 int a() {int a="x",b=2; return a+b;}
 }

 // and add one character to it such as....

 void main()
 {
 int a() {int a="x",b=2; return a+b;}
 }

 // to get the functional equivilent of...

 void main()
 {
 int a() { /+ int a="x",b=2; return a+b; +/ }
 }

 // for testing purposes, preferably letting the compiler still
 // check the code between the braces for syntax errors,
 // issuing only a warning if a syntax error is found in the disincluded code,
but not interfering with compilation
 // (although systax checking of such disincluded code should be at the option
of the compiler writer)
 // but letting it ignore any non-syntactical errors and
 // not produce any compiled code for the text between "{/" and it's matching
"}".

 This would allow logic errors to be found much more quickly.

 Actually, now that I think more about it...
 better to let the compiler ignore syntax errors also in the disincluded text...
 since removal of a single character re-includes the text so that syntax can be
checked...
 However, it would still have to tokenize the disencluded code at least enoug to
 find the "matching" close brace.

 TZ


Oops... I hate not being able to go back and edit "after posting"....  The
"modified" code should have looked like...

void main()
{
int a() {/int a="x",b=2; return a+b;}
}

Anyway, Walter... please consider this idea for some future version of D.
It's a solid idea.
The only thing I'm not sure about is which character is best to use... but "/"
seems logical.

(/ perhaps it could work with parantheses as well?)

// TZ
May 18 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Thu, 19 May 2005 01:32:36 -0500, TechnoZeus wrote:


 "TechnoZeus" <TechnoZeus PeoplePC.com> wrote in message
news:d6hbor$14pu$1 digitaldaemon.com...

 // In other words, I would like to be able to take buggy code like...

 void main()
 {
 int a() {int a="x",b=2; return a+b;}
 }

 // and add one character to it such as....

 void main()
 {
 int a() {int a="x",b=2; return a+b;}
 }

 // to get the functional equivilent of...

 void main()
 {
 int a() { /+ int a="x",b=2; return a+b; +/ }
 }

 // for testing purposes, preferably letting the compiler still
 // check the code between the braces for syntax errors,
 // issuing only a warning if a syntax error is found in the disincluded code,
but not interfering with compilation
 // (although systax checking of such disincluded code should be at the option
of the compiler writer)
 // but letting it ignore any non-syntactical errors and
 // not produce any compiled code for the text between "{/" and it's matching
"}".

 This would allow logic errors to be found much more quickly.

 Actually, now that I think more about it...
 better to let the compiler ignore syntax errors also in the disincluded text...
 since removal of a single character re-includes the text so that syntax can be
checked...
 However, it would still have to tokenize the disencluded code at least enoug to
 find the "matching" close brace.

 TZ


 
 Oops... I hate not being able to go back and edit "after posting"....  The
"modified" code should have looked like...
 
 void main()
 {
 int a() {/int a="x",b=2; return a+b;}
 }
 
 Anyway, Walter... please consider this idea for some future version of D.
 It's a solid idea.
 The only thing I'm not sure about is which character is best to use... but "/"
seems logical.
 
 (/ perhaps it could work with parantheses as well?)
 


I see now, its the "one character" aspect that appeals to you. How would
the following parse ....

 void main()
 {
   int absa(int x, int y) 
   {// This function returns the sum of the absolute values.
     return abs(x) + abs(y);
   }
 }

Is that a line comment or a commented out function body

-- 
Derek
Melbourne, Australia
19/05/2005 4:39:12 PM
May 18 2005
parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message
news:1nnsu1nqf8mx2$.qatsf3eynjxk$.dlg 40tude.net...

 On Thu, 19 May 2005 01:32:36 -0500, TechnoZeus wrote:


 "TechnoZeus" <TechnoZeus PeoplePC.com> wrote in message
news:d6hbor$14pu$1 digitaldaemon.com...

 // In other words, I would like to be able to take buggy code like...

 void main()
 {
 int a() {int a="x",b=2; return a+b;}
 }

 // and add one character to it such as....

 void main()
 {
 int a() {int a="x",b=2; return a+b;}
 }

 // to get the functional equivilent of...

 void main()
 {
 int a() { /+ int a="x",b=2; return a+b; +/ }
 }

 // for testing purposes, preferably letting the compiler still
 // check the code between the braces for syntax errors,
 // issuing only a warning if a syntax error is found in the disincluded code,
but not interfering with compilation
 // (although systax checking of such disincluded code should be at the option
of the compiler writer)
 // but letting it ignore any non-syntactical errors and
 // not produce any compiled code for the text between "{/" and it's matching
"}".

 This would allow logic errors to be found much more quickly.

 Actually, now that I think more about it...
 better to let the compiler ignore syntax errors also in the disincluded text...
 since removal of a single character re-includes the text so that syntax can be
checked...
 However, it would still have to tokenize the disencluded code at least enoug to
 find the "matching" close brace.

 TZ


 Oops... I hate not being able to go back and edit "after posting"....  The
"modified" code should have looked like...

 void main()
 {
 int a() {/int a="x",b=2; return a+b;}
 }

 Anyway, Walter... please consider this idea for some future version of D.
 It's a solid idea.
 The only thing I'm not sure about is which character is best to use... but "/"
seems logical.

 (/ perhaps it could work with parantheses as well?)


 I see now, its the "one character" aspect that appeals to you. How would
 the following parse ....

  void main()
  {
    int absa(int x, int y)
    {// This function returns the sum of the absolute values.
      return abs(x) + abs(y);
    }
  }

 Is that a line comment or a commented out function body

 -- 
 Derek
 Melbourne, Australia
 19/05/2005 4:39:12 PM


That's a line comment... "in my opinion."

Unfortunately, that's the one reason why I asked for other people to suggest a
character to use...
because I thought of that possible ambiguity and didn't like it.  Otherwise, I
would have suggested "/" right away.

I also considered the use of "+" and "*" but "+" can be a unary operator, and
"*" can be used as a pointer operator...
so like I said... which character to use is the only thing I haven't worked
out.  The rest is solid.

TZ
May 19 2005
prev sibling next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Wed, 18 May 2005 21:16:18 -0500, TechnoZeus wrote:

There is the existing 'version' statement ...

  version(none) if (true) {writef(`test %s`,st); a += b;}

would compile as...

  {}

In other words, just prefix the statement/block with 'version(none)'. I
don't think a new comment syntax is needed just yet.

-- 
Derek
Melbourne, Australia
19/05/2005 2:20:29 PM
May 18 2005
next sibling parent reply James Dunne <james.jdunne gmail.com> writes:
How about {-

I don't think the negation operation is allowed as the lvalue of an expression.
It could be done to negate a discarded return int type from a function call as
in

int foo() { ... }

if (do something) {-foo();}

However, following D's token lexer pattern, it would make the longest token
possible and in that case it would be {-, if that were to be the accepted token
to indicate a disincluded block of code.  If the user truly (moronically) wanted
to negate the discarded return value of a function call, he would have a newline
char or a space between the { and -, like so:

if (do something) { -foo(); }

I'd think this isn't really a problem to worry about.  Besides, the '-' has a
nice connotation after '{':  WARNING! BAD CODE!

I'm not sure how useful this would be aside from alleviating the coder of some
typing, using the other suggested methods.  It could have the potential to
confuse newbies, but code with disincluded code blocks should never be released
to the public. =)

Overall, I'd say you have my vote.  I wouldn't fight to the death to have it,
but it could come in handy during those late-night sleep-deprived debugging
sessions =).

In article <1bc2y8wnwoquc.16kb5fpub0i7p$.dlg 40tude.net>, Derek Parnell says...

On Wed, 18 May 2005 21:16:18 -0500, TechnoZeus wrote:

There is the existing 'version' statement ...

  version(none) if (true) {writef(`test %s`,st); a += b;}

would compile as...

  {}

In other words, just prefix the statement/block with 'version(none)'. I
don't think a new comment syntax is needed just yet.

-- 
Derek
Melbourne, Australia
19/05/2005 2:20:29 PM


Regards,
James Dunne
May 18 2005
parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"James Dunne" <james.jdunne gmail.com> wrote in message
news:d6h7q6$11vl$1 digitaldaemon.com...

 How about {-

 I don't think the negation operation is allowed as the lvalue of an expression.
 It could be done to negate a discarded return int type from a function call as
 in

 int foo() { ... }

 if (do something) {-foo();}

 However, following D's token lexer pattern, it would make the longest token
 possible and in that case it would be {-, if that were to be the accepted token
 to indicate a disincluded block of code.  If the user truly (moronically)
wanted
 to negate the discarded return value of a function call, he would have a
newline
 char or a space between the { and -, like so:

 if (do something) { -foo(); }

 I'd think this isn't really a problem to worry about.  Besides, the '-' has a
 nice connotation after '{':  WARNING! BAD CODE!

 I'm not sure how useful this would be aside from alleviating the coder of some
 typing, using the other suggested methods.  It could have the potential to
 confuse newbies, but code with disincluded code blocks should never be released
 to the public. =)

 Overall, I'd say you have my vote.  I wouldn't fight to the death to have it,
 but it could come in handy during those late-night sleep-deprived debugging
 sessions =).

 In article <1bc2y8wnwoquc.16kb5fpub0i7p$.dlg 40tude.net>, Derek Parnell says...

On Wed, 18 May 2005 21:16:18 -0500, TechnoZeus wrote:

There is the existing 'version' statement ...

  version(none) if (true) {writef(`test %s`,st); a += b;}

would compile as...

  {}

In other words, just prefix the statement/block with 'version(none)'. I
don't think a new comment syntax is needed just yet.

-- 
Derek
Melbourne, Australia
19/05/2005 2:20:29 PM


 Regards,
 James Dunne


Yeah, I thought about that as a possibility...
but then I thought about the fact that a block statement may
start with or contain only an expression statement,
and an expression statement may start with the unary operator "-" for
negation...

void main()
{
int a() {return 1;}
if(1){-a;}
}

compiles... so I think "-" won't be a good choice... but perhaps others will
feel differently about it.

So far, I like {/ ... } best.

TZ
May 18 2005
prev sibling parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message
news:1bc2y8wnwoquc.16kb5fpub0i7p$.dlg 40tude.net...

 On Wed, 18 May 2005 21:16:18 -0500, TechnoZeus wrote:

 There is the existing 'version' statement ...

   version(none) if (true) {writef(`test %s`,st); a += b;}

 would compile as...

   {}

 In other words, just prefix the statement/block with 'version(none)'. I
 don't think a new comment syntax is needed just yet.

 -- 
 Derek
 Melbourne, Australia
 19/05/2005 2:20:29 PM


I'm not suggesting that it's "needed".  Only that it would be beneficial.
Technically speaking, as long as we have raw machine language,
no other computer programming language is "needed" but
obviously that doesn't preclude their being useful.
As a matter of fact, life survived before we had computers on this planet,
so technically speaking it could be debated whether or not they are "needed" ...
but they are obviously of value in spite of that fact.

TZ
May 18 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Thu, 19 May 2005 00:37:49 -0500, TechnoZeus wrote:


 "Derek Parnell" <derek psych.ward> wrote in message
news:1bc2y8wnwoquc.16kb5fpub0i7p$.dlg 40tude.net...

 On Wed, 18 May 2005 21:16:18 -0500, TechnoZeus wrote:

 There is the existing 'version' statement ...

   version(none) if (true) {writef(`test %s`,st); a += b;}

 would compile as...

   {}

 In other words, just prefix the statement/block with 'version(none)'. I
 don't think a new comment syntax is needed just yet.

 -- 
 Derek
 Melbourne, Australia
 19/05/2005 2:20:29 PM


 
 I'm not suggesting that it's "needed".  Only that it would be beneficial.
 Technically speaking, as long as we have raw machine language,
 no other computer programming language is "needed" but
 obviously that doesn't preclude their being useful.
 As a matter of fact, life survived before we had computers on this planet,
 so technically speaking it could be debated whether or not they are "needed"
...
 but they are obviously of value in spite of that fact.


Maybe I didn't make myself clear. When I said "needed" what I meant was we
already have just what you are asking for. A simple method of commenting
out blocks of code using a lexical approach rather than a textual approach.
The 'version(none)' construct was devised just for this purpose. 

So what I should have said was that the commenting facility you ask for
would be redundant as we already have such a beastie, and thus it is
possibly not worth the effort of putting it into the language.

Using the example of yours from another post...

[original code]
  void main()
  {
    version(none) int a() {return 9;}
  }


['commented out' code]
  void main()
  {
    version(none) int a() {return 9;}
  }

or if you wanted the function to exist but not its body ....

  void main()
  {
    int a() { version(none) return 9;}
  }

So in this sense, there is no need for additional commenting styles as we
already have the required syntax construct to achieve you aim.

It also greps well, and a syntax aware editor could also pick it up.

-- 
Derek
Melbourne, Australia
19/05/2005 4:27:22 PM
May 18 2005
parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message
news:1kwf1nyuist45$.2apzri8kmu7c$.dlg 40tude.net...

 On Thu, 19 May 2005 00:37:49 -0500, TechnoZeus wrote:


 "Derek Parnell" <derek psych.ward> wrote in message
news:1bc2y8wnwoquc.16kb5fpub0i7p$.dlg 40tude.net...

 On Wed, 18 May 2005 21:16:18 -0500, TechnoZeus wrote:

 There is the existing 'version' statement ...

   version(none) if (true) {writef(`test %s`,st); a += b;}

 would compile as...

   {}

 In other words, just prefix the statement/block with 'version(none)'. I
 don't think a new comment syntax is needed just yet.

 -- 
 Derek
 Melbourne, Australia
 19/05/2005 2:20:29 PM


 I'm not suggesting that it's "needed".  Only that it would be beneficial.
 Technically speaking, as long as we have raw machine language,
 no other computer programming language is "needed" but
 obviously that doesn't preclude their being useful.
 As a matter of fact, life survived before we had computers on this planet,
 so technically speaking it could be debated whether or not they are "needed"
...
 but they are obviously of value in spite of that fact.


 Maybe I didn't make myself clear. When I said "needed" what I meant was we
 already have just what you are asking for. A simple method of commenting
 out blocks of code using a lexical approach rather than a textual approach.
 The 'version(none)' construct was devised just for this purpose.

 So what I should have said was that the commenting facility you ask for
 would be redundant as we already have such a beastie, and thus it is
 possibly not worth the effort of putting it into the language.

 Using the example of yours from another post...

 [original code]
   void main()
   {
     version(none) int a() {return 9;}
   }


 ['commented out' code]
   void main()
   {
     version(none) int a() {return 9;}
   }

 or if you wanted the function to exist but not its body ....

   void main()
   {
     int a() { version(none) return 9;}
   }

 So in this sense, there is no need for additional commenting styles as we
 already have the required syntax construct to achieve you aim.

 It also greps well, and a syntax aware editor could also pick it up.

 -- 
 Derek
 Melbourne, Australia
 19/05/2005 4:27:22 PM


There again, it's not the same thing.

For example, the following code...
void main()
{
  int a() { version(none) int b=0; return 9;}
  printf("%d",a());
}
//.......

Produces "9" as output, and...
void main()
{
  int a() version(none){ int b=0; return 9;}
  printf("%d",a());
}
/.......

will not compile.

Besides, it takes longer to type or delete the text "version(none)" than to
type or delete a single character.
That time adds up.

TZ
May 19 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Thu, 19 May 2005 02:24:19 -0500, TechnoZeus wrote:


[snip]

 

 There again, it's not the same thing.
 
 For example, the following code...
 void main()
 {
   int a() { version(none) int b=0; return 9;}
   printf("%d",a());
 }
 //.......
 
 Produces "9" as output, and...


Are you having a lend of me? 

Why don't you just code it like the docs say?

 void main()
 {
   int a() { version(none) {int b=0; return 9;} }
   printf("%d",a());
 }


 
 Besides, it takes longer to type or delete the text "version(none)" than to
type or delete a single character.
 That time adds up.


If it's time you're worried about, then don't be making mistakes in the
first place ;-)

-- 
Derek Parnell
Melbourne, Australia
19/05/2005 8:12:50 PM
May 19 2005
parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message
news:156i3pcdkdyen$.16ulh2cz3hfm8.dlg 40tude.net...

 On Thu, 19 May 2005 02:24:19 -0500, TechnoZeus wrote:


 [snip]



 There again, it's not the same thing.

 For example, the following code...
 void main()
 {
   int a() { version(none) int b=0; return 9;}
   printf("%d",a());
 }
 //.......

 Produces "9" as output, and...


 Are you having a lend of me?

 Why don't you just code it like the docs say?

  void main()
  {
    int a() { version(none) {int b=0; return 9;} }
    printf("%d",a());
  }


 Besides, it takes longer to type or delete the text "version(none)" than to
type or delete a single character.
 That time adds up.


 If it's time you're worried about, then don't be making mistakes in the
 first place ;-)

 -- 
 Derek Parnell
 Melbourne, Australia
 19/05/2005 8:12:50 PM


Sorry, not sure what "having a lend" means... but judging by the context, I
would guess the answer is no.

As for why I don't "code it as the documentation says" I never said I don't.
I'm attempting to suggest something productive here, for the sake of everyone,
not to find a way that I can write code which does nothing, just for the sake
of looks.

If I just wanted to write code that has no effect on my project,
I could write it in a module that I'm not planning to use.  That's not the
point.

Changing...
int a() {int b=0; return 9;}
into...
int a() { version(none) {int b=0; return 9;} }
takes a lot more typing and cursor positioning than typing a single character.
And removing that extra typing later requires finding exactly where it was
added...
which is easy on such a small piece of code with a single such change, but
much more invloved if you are attempting to temporarily disinclude
several large blocks of code at once, and then re-include them one block at a
time.

Is there a reason why you seem to be opposed to the idea of making things
easier for other programmers?

What I was hoping for is a discussion of which character would be best to use
for the purpose, and why.
Not a discussion of more difficult and time consuming ways to accomplish the
same task.

TZ
May 19 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Thu, 19 May 2005 12:15:32 -0500, TechnoZeus wrote:



 Is there a reason why you seem to be opposed to the idea of making things
easier for other programmers?


Just playing the devil's advocate role. 

-- 
Derek Parnell
Melbourne, Australia
20/05/2005 7:14:41 AM
May 19 2005
parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message
news:d3km0zsch9k5$.7zcva2ulaskd.dlg 40tude.net...

 On Thu, 19 May 2005 12:15:32 -0500, TechnoZeus wrote:



 Is there a reason why you seem to be opposed to the idea of making things
easier for other programmers?


 Just playing the devil's advocate role.

 -- 
 Derek Parnell
 Melbourne, Australia
 20/05/2005 7:14:41 AM


That's cool... but careful though,
because playing the devil's advocate
before a good idea has enough show of support can kill it.
People might think you really dislike the idea and would
rather not see it come to fruition,
which may lead others to think that supporting it is a waste of their time.

Please, keep in mind when choosing to play the devil's advocate role,
that there will always be people in a forum like this who are
supporters of a competing product or group of products,
and who's true intention is to slow or halt positive progress.
Give them time to speak up first,
because they don't have to "play" the devil's advocate... they are.
If that doesn't happens, and you see reasons to inject a little
skepticism into a healthy discussion... have at it... but don't over-do it.  :)

Seems Walter has already been here and gone,
but he did tell me that he tries to read every post,
so perhaps there's still a chance... if we can get a healthy discussion going.

With that in mind, I'll repeat my original question and hope there are
a few people out there who haven't already decided the idea is
doomed and decided not to follow this thread any further...

Any suggestions for what would make a good character to use to turn braces into
the logical equivilant of a comment block inside of an empty statement?

Examples are so far are...

{/ ... }
{* ... }
{+ ... }
{- ... }

and let me add...

{_ ... }
{' ... }
{~ ... }
{! ... }
{; ... }

Any comments on which one would be the best choice and why?
Please?

TZ
May 19 2005
prev sibling next sibling parent reply "Lionello Lunesu" <lio lunesu.removethis.com> writes:
I think the idea is pretty freaky :-)

But if a character should be picked, it should be '/', since all comments 
start with '/', makes it easy for the parser I guess:

if (bla) /{ ignored }

Also fixes the "if (x) {// what about this" problem.

And, it also seems obvious to me that 'bla' will get evaluated. Imagine 
that: you put a 'comment' and code before it is ignored? If you don't want 
it evaluated, insert the "0&&" before it, as mentioned by Walter et al.

If you make something freaky, at least make it consistent :-)

L.
May 19 2005
next sibling parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Lionello Lunesu" <lio lunesu.removethis.com> wrote in message
news:d6k0uj$ai7$1 digitaldaemon.com...

 I think the idea is pretty freaky :-)

 But if a character should be picked, it should be '/', since all comments
 start with '/', makes it easy for the parser I guess:

 if (bla) /{ ignored }

 Also fixes the "if (x) {// what about this" problem.

 And, it also seems obvious to me that 'bla' will get evaluated. Imagine
 that: you put a 'comment' and code before it is ignored? If you don't want
 it evaluated, insert the "0&&" before it, as mentioned by Walter et al.

 If you make something freaky, at least make it consistent :-)

 L.


Yep.  I thought of that possibility also.

Yes, everything outside of and including the braces would be treated as normal
code...
or in the case of  /{ ... } being used, everything outside of the "disincluded
block" would be
treated as normal code, and the disincluded block would be treated as {}
so that syntactically, it would be treated as an empty compound statement block.

The only thing I didn't like about placing "/" before the opening brace
is that "to me" it looks like the braces would also be treated as comment text,
(which is not what I wanted, since that would cause an error in syntax.)
but I appreciate you bringing it up so that  I can see
that at least one person thought it looks okay that way.

Anyone else care to discuss whether they prefer this /{ ... }
for a combination to be treated as {} and why?

TechnoZeus
May 20 2005
prev sibling parent reply Jay <Jay_member pathlink.com> writes:
What about the following?

bool something = true;
while (something) {?
something = do_something();
}

Or the following?

bool something;
do {?
something = do_something();
} while (something);

Or the following?

for (int i = 0; i < 100; ) {?
i += do_something();
}
May 20 2005
parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Jay" <Jay_member pathlink.com> wrote in message
news:d6k482$eib$1 digitaldaemon.com...

 What about the following?

 bool something = true;
 while (something) {?
 something = do_something();
 }

 Or the following?

 bool something;
 do {?
 something = do_something();
 } while (something);

 Or the following?

 for (int i = 0; i < 100; ) {?
 i += do_something();
 }


Look like you've been programming in C too long.  Hehe.

No, seriously though... I think you may have missed the point...
unless you are suggesting "?" placed after the opening brace to comment out the
entire contents of the compound statement... which isn't what that looks like
to me.

The idea isn't to come up with a new form of branching, or a new use for an old
one... but
rather to have a quick way to disable and re-enable a logical block of code,
by typing or deleting a single character in a single location.

I did consider something like...
{? z="ignore this text" : x="but process this text as code" }
// where x gets a string value assigned, and z is uneffected.
or...
{[ commented until matching close square bracket, or close brace, which ever
comes first] x="process this text as code" }
// where x gets a string value but the text in the "{[ ...]" block is ignored...

but they sort of defeat the porpose.... unless you allow both
{[ ignored code ] normal code }
and
{[ all ignored code }
to work.

but I'm not sure the "[" ( and "]" ) wouldn't be mistaken by the compiler
(or by a programmer) as having some other meaning in that context.

TZ
May 20 2005
prev sibling parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
"TechnoZeus" <TechnoZeus PeoplePC.com> wrote in message 
news:d6gt7l$os5$1 digitaldaemon.com...

I would like to suggest a new way of commenting out code, or more 
accurately, marking a block of code to not get compiled.

 Okay, so D already has 3 types of comments
 and most people reading this are probably wondering at this point
 how I could possibly even think of suggesting yet another...
 especially since there are much more pressing matters at hand.

 Well, what I have in mind is a way to take advantage of the lexical 
 structure of the D language to make debugging easier and more efficient.

 Right now, our choices for commenting are...
 1: A pair of characters that placed together on a line keep the rest of 
 that line from getting compiled.
 2: Two pairs of characters that placed at opposite ends of a block of text 
 will keep that text from getting compiled.
 3: Two pairs of characters that placed at opposite ends of a block of code 
 (including comments) will keep that code from getting compiled.

 I propose the following additional specification for a non-compiling 
 block..
 4. A character (or group of characters) that when placed
 directly after the "{" at the beginning of a compound statement block will 
 cause
 that statement block to be treated by the compiler as if it were empty.

 For example, if "[/]" were used as for this purpose, then....
 if (true) {[/]writef(`test %s`,st); a += b;}
 would compile as...
 if (true) {}

 I'm not sure what character or group of characters would be best for this 
 purpose,
 but it would be best if a single character could be used that never occurs 
 after "{" for any other reason,
 and could be easily spoted and recognized .

 This would allow quick disincluding of an entire logical block of code 
 with a simple modification,
 and would not require an end marker, since the matching close brace "}" 
 would mark the end of the disincluded block.

 This type of debug tagging would disable a block of code (and all 
 sub-blocks contained within that block)
 quickly and neatly, without having to locate and mark both ends of the 
 block...
 since the compiler would take care of finding the other end.

 Also, editors designed to check syntx could still syntax check within such 
 a block,
 even though it's not going to be compiled,
 since it would be considered "disincluded code",
 rather than simply "comment text".

 Anyone have a suggestion for what character to use?
 I don't expect this idea to get included into the D language any time 
 soon,
 but I'm hoping that if we can open a reasonable discussion of it,
 perhaps it would be considered for inclusion some day.

 TechnoZeus


Why is having to type 1 character so important? This feature seems like it 
isn't worth the bang-for-buck to me. Putting /+ +/around chunks is quick and 
easy. It would be a disaster to remove entire chunks of code by just one 
mistyped keystroke.
May 20 2005
parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Ben Hinkle" <ben.hinkle gmail.com> wrote in message
news:d6kk50$ri6$1 digitaldaemon.com...

 "TechnoZeus" <TechnoZeus PeoplePC.com> wrote in message
 news:d6gt7l$os5$1 digitaldaemon.com...

I would like to suggest a new way of commenting out code, or more
accurately, marking a block of code to not get compiled.

 Okay, so D already has 3 types of comments
 and most people reading this are probably wondering at this point
 how I could possibly even think of suggesting yet another...
 especially since there are much more pressing matters at hand.

 Well, what I have in mind is a way to take advantage of the lexical
 structure of the D language to make debugging easier and more efficient.

 Right now, our choices for commenting are...
 1: A pair of characters that placed together on a line keep the rest of
 that line from getting compiled.
 2: Two pairs of characters that placed at opposite ends of a block of text
 will keep that text from getting compiled.
 3: Two pairs of characters that placed at opposite ends of a block of code
 (including comments) will keep that code from getting compiled.

 I propose the following additional specification for a non-compiling
 block..
 4. A character (or group of characters) that when placed
 directly after the "{" at the beginning of a compound statement block will
 cause
 that statement block to be treated by the compiler as if it were empty.

 For example, if "[/]" were used as for this purpose, then....
 if (true) {[/]writef(`test %s`,st); a += b;}
 would compile as...
 if (true) {}

 I'm not sure what character or group of characters would be best for this
 purpose,
 but it would be best if a single character could be used that never occurs
 after "{" for any other reason,
 and could be easily spoted and recognized .

 This would allow quick disincluding of an entire logical block of code
 with a simple modification,
 and would not require an end marker, since the matching close brace "}"
 would mark the end of the disincluded block.

 This type of debug tagging would disable a block of code (and all
 sub-blocks contained within that block)
 quickly and neatly, without having to locate and mark both ends of the
 block...
 since the compiler would take care of finding the other end.

 Also, editors designed to check syntx could still syntax check within such
 a block,
 even though it's not going to be compiled,
 since it would be considered "disincluded code",
 rather than simply "comment text".

 Anyone have a suggestion for what character to use?
 I don't expect this idea to get included into the D language any time
 soon,
 but I'm hoping that if we can open a reasonable discussion of it,
 perhaps it would be considered for inclusion some day.

 TechnoZeus


 Why is having to type 1 character so important? This feature seems like it
 isn't worth the bang-for-buck to me. Putting /+ +/around chunks is quick and
 easy. It would be a disaster to remove entire chunks of code by just one
 mistyped keystroke.


It's not the fact that it's a single keystroke that's important.
That's just a handy side effect if a single character is used.
Since it would only work if the correct character was typed in the correct
position,
there is little chance of "accidentally" commenting out a block of code.

What's important is that it specifically disincludes the contents of a compound
statement block as a single logical unit,
and that the entire textual change is located in a single location.

The main reason it's important that it disincludes the contents of a compound
statement block as a single unit is
because doing so is a quick and common way to narrow down the possible location
of a logic error.

The main reason it's important that the entire textual change be done in a
single location is that it makes
reversing any such change a straightforward and fool-proof process.

Consider for example, the case where a programmer decides to
comment out several blocks of code that may be connected in some way
to a particular problem, and then to uncomment those blocks one at a time
and test the results at each stage.

The way things are now, they would first have to locate both the beginning and
end of
each block of code and add the begin and end comment tags accordingly.  Then,
at each stage, they would have to find both the beginning and end of a specific
commented block,
and remove the comment markers.
Unless they are using an editor that can remove both tags at the same time,
they run into the situation where removing one makes it harder to locate and
correctly match the other.
Not much of a problem in short source code files, but a definate concern in
larger ones.

The ability to comment out such a logical block with the
insertion of a single character at the beginning of the block,
would eliminate the need to match up begin and end comment tags
when removing them, allowing more complex testing to be
accomplished much more easily and with less risk of error in the process.

TZ
May 20 2005