nesting coments

[Richard Harnden]

[Leor: using POD to "comment out" Perl code]
[Dan: don't do that]
[Leor: then what?]
[Dan: use goto]
[Arthur: that's even worse]

(e-mail address removed) (Dan Pop) wrote:

[...]

I prefer the goto method because it works in all the languages I'm
currently using. Well chosen label names make its usage for this
particular purpose obvious.

[...]

I'm not a perl expert, but I just have to ask: how do you deal with
the other side effects Arthur mentioned:

AJO> Secondly, 'goto' does NOT remove the offending code from the
AJO> program! It will still be not only parsed, but actually run:
AJO> any 'my' variables in the "commented-out" section will get
AJO> declared, for example. So you'll end up with errors at best,
AJO> and silent bugs at worst.

So ... if you use goto to skip over code that introduces new variables, and
then you later try to use them and your program crashes because either they
aren't there or they contain junk, then surely you didn't comment out
*enough* code.

Or am I missing something ?

 

[Michael Wojcik]

My father used to tell me sometimes "You'll be a man before your
mother is." It will be a very long time before C# is any kind of
member of the "C family", in spite of the bookstores which seem to
think it is. C# is much closer to Java than C. Yes, I'm aware that
some people consider Java a "better C", but that gets harder to
maintain with each new Java release.

It depends on what you consider a language "family", of course.
I think of Java and C# as, oh, cousins (perhaps not first cousins)
of C, since they adopt significant chunks of C (and C++) syntax and
semantics.

But it's also certainly true that there are huge differences between
Java and C# on the one hand, and C++ on the other, and of course C
is even further. So if you prefer, read my statement as "before C#
becomes more prevalent than C (or C++ or Java)". (I suppose it
might have an outside, long-term chance against Java.)

 

[Leor Zolman]

For some strange reason, my Perl code is ressembling to my C code.

The best way for a C programmer to learn Perl is to get only the most
basic features (data types, operators, file I/O) and start writing code
using the C syntax. If the interpreter complains about syntax errors,
figure out the *minimal* changes required to make it happy.

Well, that's /one/ way, but not necessarily the best way. Just as there are
at least two ways for a C programmer to learn C++, the "old-fashioned" way
(start by writing Yet Another String Class, etc.) and the modern way (a la
Accelerated C++), the same sort of thing applies to learning Perl. In the
case of Perl, though, I think it could be even more damaging to do what you
suggested up there than it is in the parallel case of learning C++ that
way.

Perl, being highly idiomatic, provides many succinct native
(non-function/operator, at least in part) constructs for doing things that
require lots of function calls in C. For example, there are some really
nice Perl features (involving $`, $& and $') that I didn't know about
until I'd already written a lot of code that did things the "C" way, using
functions such as index and substr. To this day, I haven't gone back and
changed any of it, adhering to the "If it aint broke, don't fix it" rule
(which I finally learned quite well by working for Robert Ward at CUJ).
Nevertheless, I have no doubt that I could improve both the performance and
the clarity of my Perl code by going back and re-working those sections to
take advantage of the features I didn't know about.

So I'd have to say that the "best" way for a C programmer to learn Perl is
to try to forget everything he/she knows about C, and read a good Perl book
/before/ trying to write code to emulate the behavior of a C program (or
even to just do things the "C way").
-leor

 

[Irrwahn Grausewitz]

[Leor: using POD to "comment out" Perl code]

[Dan: don't do that]
[Leor: then what?]
[Dan: use goto]
[Arthur: that's even worse]
[Dan: I prefer the goto method]

[Irrwahn: what about Arthur's objection:]

AJO> Secondly, 'goto' does NOT remove the offending code from the
AJO> program! It will still be not only parsed, but actually run:
AJO> any 'my' variables in the "commented-out" section will get
AJO> declared, for example. So you'll end up with errors at best,
AJO> and silent bugs at worst.

So ... if you use goto to skip over code that introduces new variables, and
then you later try to use them and your program crashes because either they
aren't there or they contain junk, then surely you didn't comment out
*enough* code.

Right, but you're not _guaranteed_ to notice that something went
terribly wrong, until Friday afternoon. Cf. undefined behaviour
caused by use of uninitialized variables in C.

Or am I missing something ?

The main objection? 'goto' is just not an appropriate construct to
hide code from the translator, in any language I can think of right
now. If I were seriously suggesting a similar approach in C, Dan
would certainly call me a patent idiot, and rightfully so.

Regards

 

[Keith Thompson]

For some strange reason, my Perl code is ressembling to my C code.

The best way for a C programmer to learn Perl is to get only the most
basic features (data types, operators, file I/O) and start writing code
using the C syntax. If the interpreter complains about syntax errors,
figure out the *minimal* changes required to make it happy.

Taking the K&R2 newbie program already discussed in another thread as an
example:

#!/usr/local/bin/perl -w

my ($fahr, $celsius);
my ($lower, $upper, $step);

$lower = 0;
$upper = 300;
$step = 20;

$fahr = $lower;
while ($fahr <= $upper) {
$celsius = 5 * ($fahr - 32) / 9;
printf("%d\t%d\n", $fahr, $celsius);
$fahr = $fahr + $step;
}

The only change I had to do in the "meat" of the program was adding the
dollar signs in front of each variable.

I'd add "use strict;" at the top to enable stronger error checking.
(I use both "-w" and "use strict;" in all my Perl programs.)

This program actually does something quite different from the C
version. The calculation of $celsius is done in floating-point, not
in integer arithmetic. The results are displayed as integers because
of the "%d" specifiers in the printf. Perl's printf, unlike C's,
knows the actual types of its arguments, and converts them as
necessary. You can see the real values by changing the printf to:

print "$fahr\t$celsuis\n";

or, if you prefer to be more C-like:

printf("%g\t%g\n", $fahr, $celsius);

Anyway, the thread is actually about commenting out blocks of code.
It would never occur to me to use goto for this in any language;
any time this would work:

goto END_OF_SKIPPED_SECTION;
... lots of code here
END_OF_SKIPPED_SECTION:

this would work better:

if (0) {
... lots of code here
}

In Perl, it's also not very helpful if I want to comment out a
subroutine definition.

But in Perl, if I want to comment out a block of code, I just comment
it out, inserting a '#' at the beginning of each line. Most text
editors should let you do this in a few keystrokes, and the result is
a block of code that's unmistakably commented out.

This is, of course, a matter of style; YMMV.

 

[Arthur J. O'Dwyer]

[Leor: using POD to "comment out" Perl code]
[Dan: don't do that]

I prefer the goto method because it works in all the languages I'm
currently using. Well chosen label names make its usage for this
particular purpose obvious.

AJO> Secondly, 'goto' does NOT remove the offending code from the
AJO> program! It will still be not only parsed, but actually run:
AJO> any 'my' variables in the "commented-out" section will get
AJO> declared, for example. So you'll end up with errors at best,
AJO> and silent bugs at worst.

So ... if you use goto to skip over code that introduces new variables,
and then you later try to use them and your program crashes because
either they aren't there or they contain junk, then surely you didn't
comment out *enough* code.

Or am I missing something ?

I don't know enough Perl to give you a concrete example, but I'd
look for situations like this:

goto new_version; # OLD VERSION -- SKIP IT
my @bigtable;
new_version: # NEW VERSION
my %bigtable; # much better!

# do something accessing a member of 'bigtable'

Perl *will* do weird things if you use $ or # on a hash as if it were
an array, or vice versa. And then of course there's always the
pathological cases... ;-)

goto new_version; # OLD VERSION -- SKIP IT
while ($foo) {
if (bar()) goto done;
}
done:
new_version: # NEW VERSION
while ($foo) {
if (new_improved_bar()) goto done;
}
done:

But if you want real answers, I still encourage you to talk to a
Perl hacker, in a Perl newsgroup. My work here is done.

-Arthur,
over and out

 

[Keith Thompson]

I don't know enough Perl to give you a concrete example, but I'd
look for situations like this:

goto new_version; # OLD VERSION -- SKIP IT
my @bigtable;
new_version: # NEW VERSION
my %bigtable; # much better!

# do something accessing a member of 'bigtable'

Perl *will* do weird things if you use $ or # on a hash as if it were
an array, or vice versa. And then of course there's always the
pathological cases... ;-)

See, this is why we usually don't discuss Perl in comp.lang.c.
@bigtable (an array) and %bigtable (a hash) are two different
variables; the syntax is such that references to them are unambiguous.

 

[Dan Pop]

This program actually does something quite different from the C
version.

The two programs have the same specification and generate identical
output. The rest is irrelevant...

Dan