On Dec 30, 2007 6:10 PM, Jonathan Lang wrote:
> Short answer: the compiler has no way of knowing whether the
> programmer wants an embedded comment or a line comment; so instead of
> guessing, it requires the programmer to disambiguate.


>   # if ($test)
>   # {
>     .say;
>   # } else {
>   #   .doit;
>   # }
> or
>    #{ start here } if ($test)
>   {
>     .say;
>   } else {
>     .doit;
>   }
> --
> Jonathan "Dataweaver" Lang

This feature is horrible :(

I'm sure many people will be confused and badly surprised when
commenting out code and getting un-expected errors or worse behaviour
they didn't expect. It forces me as a Perl programmer to pay attention
to whitespace at locations where whitespace, for me, has always been

my @arr =
   #(1,2,3); # older values, don't use...
   (4,5,6); # correct set of values

Oops compiler error? Or strange behavior? If I wanted to be careful of
my whitespace I would be writing Python...

 #(  commenting out a large code section, yey for Perl6 multi-line comments...
   if ($foo) {
      print "...or not :(\n"
) # this should have been the end of the embedded comment

This is like that thing that makes me hate Tcl comments, you know,
bracers in comments causing compiler errors...

Comments are a some of the most commonly used constructs in code.
Every code has them, even the simplest script. If you have to "get
around" a limitation whenever using them (your words - "but it's easy
enough to get around that restriction") you're doing something wrong
with their design. Where is the sense in making the closing of the
embedded comment a single bracket only?

I know a lot of very smart people are working on the design of Perl 6
and have no problem keeping their sample Perl6 code working with the
new comment system. But you have to remember the typical Perl user (I
am one and I meet others at work ;)) is not going to like getting
spurious compiler errors, only to find out he did leave (or didn't
leave) a whitespace before (or after) his comment char (see how
confusing that sounds?), or that his multi-line comment closed
un-expectedly by a single brace. I can already see the debugging

I think the Perl 5 method of having just # for single-line and =pod
for multi-line was better. Yes simple Perl users I know didn't use
=pod but it was there if they needed it. A good script-able editor was
really all that was needed if you wanted to comment or un-comment
several lines at once.
Maybe some people will even argue that "=pod" is too confusing - you
need to worry about whitespace there too which is bad - but at least
you could not close that multi-line by accident.

Please stick with what works, don't build a solution that is worse
than the problem it is meant to solve...

Best regards,
Offer Kaye

Reply via email to