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