Re: multi-line comments, C macros, Pod abuse
On Mon, Aug 21, 2006 at 12:06:36AM +0100, Andrew Suffield wrote:
On Sun, Aug 20, 2006 at 03:55:56PM -0600, Luke Palmer wrote:
Why would you care about introducing a new lexical scope? You would
care about that if you used a variable you declared in the commented
code in the code below it, which is broken.
Typically because you have several versions that you want to switch
between, and you'd rather add a few characters of comment rather than
spend the time rearranging the code to use ifs or subs or
something. It's something you might do when debugging or experimenting
(especially under time pressure) - at least, that's how I use '#if 0'
in C.
The more I think about this issue the more I realize that this is really
a very simple case of metaprogramming. Which got me thinking about more
sophisticated compile time flow control. I imagine that defining
something like a compile time switch switch statement is possible with
the existing macros. Would anyone like to take a shot at defining a
macro to do this? Is it possible to jump to something outside of a
macros input that is also evaluated at compile time?
Using '#END' (or rather, q:to'#END') is actually not that bad an
idea... it'd work in most places where #{} would give trouble. Unless
anybody has any better ideas, that could be a useful idiom to
remember.
Using heredocs for commenting code out is slightly undesirable as it
would create a branch that has to be tested at runtime. One would hope
that the compiler would note the conditional on a constant and throw the
heredoc out as dead code but it certainly feels untidy.
-J
--
pgpCLflaAtQID.pgp
Description: PGP signature
Re: multi-line comments, C macros, Pod abuse
I think this is not even a metaprogramming issue so much as a
programming environment one. I mean, if your editor doesn't make it
easy to stick a # at the beginning of a bunch of lines with one
action, and likewise remove them later, you need to get a new editor.
:)
On 8/21/06, Joshua Hoblitt [EMAIL PROTECTED] wrote:
On Mon, Aug 21, 2006 at 12:06:36AM +0100, Andrew Suffield wrote:
On Sun, Aug 20, 2006 at 03:55:56PM -0600, Luke Palmer wrote:
Why would you care about introducing a new lexical scope? You would
care about that if you used a variable you declared in the commented
code in the code below it, which is broken.
Typically because you have several versions that you want to switch
between, and you'd rather add a few characters of comment rather than
spend the time rearranging the code to use ifs or subs or
something. It's something you might do when debugging or experimenting
(especially under time pressure) - at least, that's how I use '#if 0'
in C.
The more I think about this issue the more I realize that this is really
a very simple case of metaprogramming. Which got me thinking about more
sophisticated compile time flow control. I imagine that defining
something like a compile time switch switch statement is possible with
the existing macros. Would anyone like to take a shot at defining a
macro to do this? Is it possible to jump to something outside of a
macros input that is also evaluated at compile time?
Using '#END' (or rather, q:to'#END') is actually not that bad an
idea... it'd work in most places where #{} would give trouble. Unless
anybody has any better ideas, that could be a useful idiom to
remember.
Using heredocs for commenting code out is slightly undesirable as it
would create a branch that has to be tested at runtime. One would hope
that the compiler would note the conditional on a constant and throw the
heredoc out as dead code but it certainly feels untidy.
-J
--
--
Mark J. Reed [EMAIL PROTECTED]
Re: multi-line comments, C macros, Pod abuse
On Sat, Aug 19, 2006 at 02:26:28AM +, Luke Palmer wrote:
On 8/19/06, Aaron Crane [EMAIL PROTECTED] wrote:
You don't actually need a macro in that case:
if 0 { q
...
}
Which, of course, eliminates the original desire to have a
code-commenting construct where you just change the 0 to a 1. After
all, we already have #{}. Incidentally, you could consider that the
desired construct, because it balances, and a closure at statement
level executes itself:
#{
if $baz {
$foo.bar
}
}
To uncomment, remove the # before the {.
This is exactly the type of construct that I had in mind. A couple of
questions. Is code inside of a #{}:
- parsed and required to be syntacticly correct?
- does it still appear in emitted code?
- what happens when a goto tries to enter into this block
or a nested sub is invoked?
- will the optimizer spend time on this block?
-J
--
pgpBcbDq8OUQ3.pgp
Description: PGP signature
Re: multi-line comments, C macros, Pod abuse
On 8/20/06, Joshua Hoblitt [EMAIL PROTECTED] wrote:
This is exactly the type of construct that I had in mind. A couple of
questions. Is code inside of a #{}:
- parsed and required to be syntacticly correct?
No. It's a comment. # followed by one or more open bracket characters
creates a comment that lasts until the matching closing bracket
character(s). It is otherwise exactly treated as single-line
comments. So:
- does it still appear in emitted code?
Not sure what you mean here.
- what happens when a goto tries to enter into this block
It fails because the label it's referencing doesn't exist.
or a nested sub is invoked?
Ditto.
- will the optimizer spend time on this block?
No.
Note, however, that Luke's example is incorrect according to S02. A
line beginning with #{ doesn't start a bracketed comment; it's treated
as a single-line comment. You need to put something before the # on
the line.
--
Mark J. Reed [EMAIL PROTECTED]
Re: multi-line comments, C macros, Pod abuse
On Sun, Aug 20, 2006 at 10:50:31AM -1000, Joshua Hoblitt wrote:
#{
if $baz {
$foo.bar
}
}
To uncomment, remove the # before the {.
This is exactly the type of construct that I had in mind. A couple of
questions. Is code inside of a #{}:
- parsed and required to be syntacticly correct?
- does it still appear in emitted code?
- what happens when a goto tries to enter into this block
or a nested sub is invoked?
- will the optimizer spend time on this block?
The important question here is this one:
- when 'uncommented', is it a no-op?
Which isn't true for #{}/{}, because {} introduces new lexical
scope. It's still a pretty good idea, but it's not as good as the C
preprocessor. if (0) has the same problem. Pod doesn't. Anybody able
to think up a non-pod construct that doesn't affect the code it wraps?
(Solutions which involve complicated modules are acceptable, so long
as the usage is not complicated and there is no run-time penalty)
Re: multi-line comments, C macros, Pod abuse
On Sun, Aug 20, 2006 at 10:50:31AM -1000, Joshua Hoblitt wrote:
: On Sat, Aug 19, 2006 at 02:26:28AM +, Luke Palmer wrote:
: On 8/19/06, Aaron Crane [EMAIL PROTECTED] wrote:
: You don't actually need a macro in that case:
:
: if 0 { q
: ...
: }
:
: Which, of course, eliminates the original desire to have a
: code-commenting construct where you just change the 0 to a 1. After
: all, we already have #{}. Incidentally, you could consider that the
: desired construct, because it balances, and a closure at statement
: level executes itself:
:
: #{
: if $baz {
: $foo.bar
: }
: }
:
: To uncomment, remove the # before the {.
The idiom would probably want to be \#{ to avoid falling afoul of the
rule that says a # in the first column is always a line-ending comment.
That's because some people would rather let their editor comment out a
block of code like this:
#{
#if $baz {
#$foo.bar
#}
#}
That has the benefit of making all the lines look like comments, and if
you're editor supports it, it's not difficult to change back. Anyway,
we're trying to support both approaches, so use \#{...} if you want the
brackets to do the delimiting. Maybe people will just get in the habit
of using \#{...} for all embedded comments. I suppose we could even go
as far as to require it, but maybe that's overkill.
: This is exactly the type of construct that I had in mind. A couple of
: questions. Is code inside of a #{}:
:
: - parsed and required to be syntacticly correct?
: - does it still appear in emitted code?
: - what happens when a goto tries to enter into this block
: or a nested sub is invoked?
: - will the optimizer spend time on this block?
It's a comment, so it's all just whitespace as far as the parser
is concerned.
Larry
Re: multi-line comments, C macros, Pod abuse
On 8/20/06, Andrew Suffield [EMAIL PROTECTED] wrote:
On Sun, Aug 20, 2006 at 10:50:31AM -1000, Joshua Hoblitt wrote:
#{
if $baz {
$foo.bar
}
}
To uncomment, remove the # before the {.
This is exactly the type of construct that I had in mind. A couple of
questions. Is code inside of a #{}:
- parsed and required to be syntacticly correct?
- does it still appear in emitted code?
- what happens when a goto tries to enter into this block
or a nested sub is invoked?
- will the optimizer spend time on this block?
The important question here is this one:
- when 'uncommented', is it a no-op?
Which isn't true for #{}/{}, because {} introduces new lexical
scope. It's still a pretty good idea, but it's not as good as the C
preprocessor. if (0) has the same problem. Pod doesn't. Anybody able
to think up a non-pod construct that doesn't affect the code it wraps?
(Solutions which involve complicated modules are acceptable, so long
as the usage is not complicated and there is no run-time penalty)
Well, I think you are being too picky.
Why would you care about introducing a new lexical scope? You would
care about that if you used a variable you declared in the commented
code in the code below it, which is broken. If you are still not
satisfied, you might try:
'#EOC';
.. commented out code ..
#EOC
And put the code back into effect by commenting out the '#EOC' line.
Of course, that changes the last statement evaluated, which isn't
good because the code above it (which is supposed to have code below
it making it forget about its last statement evaluated) must maintain
its last statement evaluated.
You can't use Pod, because you have to insert two characters instead
of changing one to uncomment some code.
And, since you are open to using complicated modules, I suppose using
a module like:
use C::Preprocessor::IfZero;
is out of the question because its implementation would only be a
couple of lines.
Yep, I think we need to add a feature to perl to support commenting
and uncommenting code easily.
Luke
Re: multi-line comments, C macros, Pod abuse
On 8/20/06, Luke Palmer [EMAIL PROTECTED] wrote: Well, I think you are being too picky. [snip snarky sarcastic rant] Hmm, perhaps I'm feeling edgy. Or maybe some of the comments reminded me of those rediculously long, whiny threads. Anyway, that was un-called-for. Luke
Re: multi-line comments, C macros, Pod abuse
On Sun, Aug 20, 2006 at 03:55:56PM -0600, Luke Palmer wrote:
The important question here is this one:
- when 'uncommented', is it a no-op?
Which isn't true for #{}/{}, because {} introduces new lexical
scope.
Why would you care about introducing a new lexical scope? You would
care about that if you used a variable you declared in the commented
code in the code below it, which is broken.
Typically because you have several versions that you want to switch
between, and you'd rather add a few characters of comment rather than
spend the time rearranging the code to use ifs or subs or
something. It's something you might do when debugging or experimenting
(especially under time pressure) - at least, that's how I use '#if 0'
in C.
Using '#END' (or rather, q:to'#END') is actually not that bad an
idea... it'd work in most places where #{} would give trouble. Unless
anybody has any better ideas, that could be a useful idiom to
remember.
Re: multi-line comments, C macros, Pod abuse
On Sat, Aug 19, 2006 at 02:26:28AM +, Luke Palmer wrote:
On 8/19/06, Aaron Crane [EMAIL PROTECTED] wrote:
You don't actually need a macro in that case:
if 0 { q
...
}
Which, of course, eliminates the original desire to have a
code-commenting construct where you just change the 0 to a 1. After
all, we already have #{}. Incidentally, you could consider that the
desired construct, because it balances, and a closure at statement
level executes itself:
#{
if $baz {
$foo.bar
}
}
To uncomment, remove the # before the {.
Or in the same vein
if 0 { q
# }
To uncomment the real code, add # before the if.
Although it is visually complex.
Nicholas Clark
Re: multi-line comments, C macros, Pod abuse
Stuart Cook schreef:
Larry Wall:
if 0 {
...
}
The one disadvantage of that approach is that it will break if the
commented-out code temporarily fails to compile.
How frequent does that happen?
And in that case s/if 0/\#/, as Luke mentioned.
And if the compile failure has to do with {}, use other braces.
But would the following work?
0 or q:to/END42/
...
END42
--
Affijn, Ruud
Gewoon is een tijger.
Re: multi-line comments, C macros, Pod abuse
Stuart Cook schreef:
Larry Wall:
if 0 {
...
}
The one disadvantage of that approach is that it will break if the
commented-out code temporarily fails to compile.
How frequent does that happen?
All the time. I often comment out bits of code while I'm refactoring or
such, because I've removed some functions or that the code depends on
s.t. it won't compile any more, I want to compile it to check that the
bits I've done work, and I want the commented-out code visible to remind
me to rewrite it later.
And in that case s/if 0/\#/, as Luke mentioned.
And if the compile failure has to do with {}, use other braces.
As you say, alternatives are available.
But would the following work?
0 or q:to/END42/
...
END42
Shouldn't it be C0 and if you don't want the RHS (or C1 or, I
suppose)? In either case, wouldn't this have the side-effect of setting
the last-evaluated value, which might also be undesired.
--
I will take my life into my hands And I will use it.'MacArthur Park'
I will win the worship in their eyes And I will lose it. Jimmy Webb
I will have the things that I desire(( http://surreal.istic.org/
And my passion flow like rivers to the sky (( It's like a DEATH CIRCUS!
pgpsHubb64lJ2.pgp
Description: PGP signature
Re: multi-line comments, C macros, Pod abuse
On Fri, Aug 18, 2006 at 11:58:20AM -1000, Joshua Hoblitt wrote:
: It occurred to me that other day that in our in house C code we
: somewhat frequently use an idiom that's not easily translated into Perl
: 5. Our rule is that if your commenting out more then 1 or 2 lines of
: code that you wrap it in a CPP if statement. The logic being that
: if you haven't deleted the code then it must have some reason of hanging
: around (and you may actually want to use it again someday). This is most
: often the case with specialized debugging code. E.g.
:
: #if 0
: ...
: #endif
if 0 {
...
}
: The great thing about this is that the you only have to flip the 0 to 1
: to re-enable the code. E.g.
:
: #if 1
: (magic now happens)...
: #endif
if 1 {
(magic now happens)...
}
Larry
Re: multi-line comments, C macros, Pod abuse
On 8/19/06, Larry Wall [EMAIL PROTECTED] wrote:
if 0 {
...
}
The one disadvantage of that approach is that it will break if the
commented-out code temporarily fails to compile. If that's a
problem, though, you could always write your own macro.
Stuart Cook
Re: multi-line comments, C macros, Pod abuse
Stuart Cook writes:
On 8/19/06, Larry Wall [EMAIL PROTECTED] wrote:
if 0 {
...
}
The one disadvantage of that approach is that it will break if the
commented-out code temporarily fails to compile. If that's a
problem, though, you could always write your own macro.
You don't actually need a macro in that case:
if 0 { q
...
}
And if you have unbalanced quote-delimiting brackets in the ..., you can
switch to different bracketing characters (including arbitrary Ps/Pe or
bidi-mirroring Unicode pairs), or simply add more brackets:
if 0 { q
... # with unmatched pointies
}
--
Aaron Crane
Re: multi-line comments, C macros, Pod abuse
On 8/19/06, Aaron Crane [EMAIL PROTECTED] wrote:
You don't actually need a macro in that case:
if 0 { q
...
}
Which, of course, eliminates the original desire to have a
code-commenting construct where you just change the 0 to a 1. After
all, we already have #{}. Incidentally, you could consider that the
desired construct, because it balances, and a closure at statement
level executes itself:
#{
if $baz {
$foo.bar
}
}
To uncomment, remove the # before the {.
Luke
