multi-line comments, C macros, & Pod abuse

#if 0
...
#endif

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

The best equivalent I've been able to come up with in Perl 5 is:

=for off
...
=cut

&

#=for off
(magic now happens)...
=cut

Except that now this requires all sorts of weird voodoo to keep the Pod
formatting from breaking.

This thread seems to suggest the situation isn't going to change much if
at all in Perl 6:

http://groups.google.com/group/perl.perl6.language/browse_thread/thread/45f5be3ca97d1d82/cd5f1daa256be9b9?lnk=gst&q=multiline+comments&rnum=1#cd5f1daa256be9b9

I guess the point I'm trying to make here is that multi-line comments
about the code and disabled chunks of code are or should be distinct
functionalities. One can make the argument that any code you want to
disable in the manner I've described should be factored out into it's
own function, so that just the call to the function can be commented
out. The hard reality is that it's not always so easy or desirable to
do that. Is there any hope of getting some equivalent "disabled code
chunk" functionality in the perl6 core?

Cheers,

-J

--

if 0 {
...
}

: The great thing about this is that the you only have to flip the 0 to 1

if 1 {
(magic now happens)...
}

Larry

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

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

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

Or in the same vein

if 0 { q<
....
# > }

To uncomment the real code, add # before the if.

Although it is visually complex.

Nicholas Clark

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

As you say, alternatives are available.

Shouldn't it be C<0 and> if you don't want the RHS (or C<1 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!

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

--

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)

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:

Not sure what you mean here.

It fails because the label it's referencing doesn't exist.

Ditto.

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 <mark...@mail.com>

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

It's a comment, so it's all just whitespace as far as the parser
is concerned.

Larry

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

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

> Why would you care about introducing a new lexical scope? You would

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.

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

--