Amir E. Aharoni wrote:
> On 30/12/2007, Jonathan Lang <[EMAIL PROTECTED]> wrote:
> > The only wart
> > is that '#( ... )' cannot begin at the very start of a line; but it's
> > easy enough to get around that restriction - say, with some leading
> > whitespace.
>
> Thanks for the reply - can you please what is the problem with having
> it in the beginning of the line?
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.
Long answer: a standard method of commenting out code is to manually
prefix each line with a '#'. If embedded comments were allowed at the
beginning of a line, then people using this technique would
occasionally get some nasty surprises. For example:
if ($test)
{
.say;
} else {
.doit;
}
Let's say that the programmer in question wants to comment out all but
the third line; so he prefixes everything else with '#':
#if ($test)
#{
.say;
#} else {
# .doit;
#}
What the writer _wants_ this to do is the equivalent of:
.say;
What he'd get with embedded comments would be the equivalent of:
else {
--
Initially, the rule was that any line beginning with a '#' would be
considered a line comment, regardless of what the second character is.
The result was that the above code worked as expected. However, it
lead to the possibility of someone putting a '#{' at the start of a
line, expecting an embedded comment, and getting a line comment
instead:
#{ start here } if ($test)
{
.say;
} else {
.doit;
}
There's no way for the compiler to reliably guess which semantics the
programmer intended, so it complains. The easiest way to keep it from
complaining is to add some whitespace:
# if ($test)
# {
.say;
# } else {
# .doit;
# }
or
#{ start here } if ($test)
{
.say;
} else {
.doit;
}
--
Jonathan "Dataweaver" Lang
