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

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

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

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

"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

"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

"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 ... }

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

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

"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