Re: Multiline/embedded comments
> On 12/22/20, Vadim Belman wrote:
>>
>> You interpret it incorrectly. The problem is in your '#`{' comment
On 12/23/20, Parrot Raiser <1parr...@gmail.com> wrote:
> Removing the space between the #` and { changes the error message to:
>
> ===SORRY!=== Error while compiling /home/guru/bin/comment_test
> Couldn't find terminator } (corresponding { was at line 12)
> at /home/guru/bin/comment_test:19
> --> ⏏
> expecting any of:
> }
>
> Should the parser not ignore anything between the start of the comment
> and the corresponding right-hand end, regardless of what is inside,
> whether it looks like code or not? Obviously, it has to go through the
> text to find the matching end character, but should it be looking for
> pairs inside? If it would be unreasonably difficult to change the
> mechanism, then it needs to be described.
>
> A note in the documents about the significance of whitespace after the
> backtick would be good. I'd suggest changing the second line of the
> definition from:
"bracketing character, and end with the matching closing bracketing
character. Only the paired "
to read:
bracketing character, and end with the matching closing bracketing
character. Whitespace is not permitted between the backtick and the
bracketing character; it will be treated as a single-line comment.
Only the paired...
If the internal pairing is to be required, I suggest the line in the
last paragraph be changed from:
"until the very end of the string. You may also use multiple curly braces.."
to read
until the very end of the string. If the opening bracketing character
occurs in the body of the comment, e.g. #`[ This is a box [ of stuff ]
], it must have a paired closing character, as shown. You may also use
multiple curly braces...
Re: Multiline/embedded comments
You interpret it incorrectly. The problem is in your '#`{' comment. You have a
space between the backtick and the opening brace. Therefore it's interpreted as
a single line comment. Though even if you remove the space the compiler will
complain because it wouldn't find closing } due to unbalanced opening one at
line 13. Note that comments treated as-is literally, backslash doesn't escape
the brace. To get what you want you might use '#`{{ ... }}` form of
opening/closing braces. In this case Rakudo will not try to balance the sinlge
opening one inside the comment.
Best regards,
Vadim Belman
> On Dec 22, 2020, at 7:59 PM, Parrot Raiser <1parr...@gmail.com> wrote:
>
> While playing around with the bounding characters for the #` form, I
> encountered an unexpected feature, which may or may not be a bug. If
> the left bounding character (e.g. the { in #`{ occurs unbalanced in
> the commented text, the compiler apparently treats it as code,
> searches for the right bounder, and generates an error if it can't
> find one. e.g.
>
> 1 #! /home/guru/bin/raku
> 2
> 3 # comment_test
> 4
> 5 # Input
> 6 # Purpose of program - test multi-line comments
> 7
> 8 #`(
> 9 put " () fails";
> 10 )
> 11
> 12 #` {
> 13 put "\{ fails";
> 14 }
> 15
> 16 put "Done";
> 17
> 18 # End comment_test Last changed: 2020-12-22 19:40:07
>
> produces
>
> ===SORRY!=== Error while compiling /home/guru/bin/comment_test
> Unexpected closing bracket
> at /home/guru/bin/comment_test:14
> --> ⏏}
>
> Removing the escape \ on line 13 generates a different but related error.
>
> Is this a limitation that should be mentioned in the description of
> the form, or the compiler mistakienly working on something it's just
> been told to ignore?
>
Multiline/embedded comments
While playing around with the bounding characters for the #` form, I
encountered an unexpected feature, which may or may not be a bug. If
the left bounding character (e.g. the { in #`{ occurs unbalanced in
the commented text, the compiler apparently treats it as code,
searches for the right bounder, and generates an error if it can't
find one. e.g.
1 #! /home/guru/bin/raku
2
3 # comment_test
4
5 # Input
6 # Purpose of program - test multi-line comments
7
8 #`(
9 put " () fails";
10 )
11
12 #` {
13 put "\{ fails";
14 }
15
16 put "Done";
17
18 # End comment_test Last changed: 2020-12-22 19:40:07
produces
===SORRY!=== Error while compiling /home/guru/bin/comment_test
Unexpected closing bracket
at /home/guru/bin/comment_test:14
--> ⏏}
Removing the escape \ on line 13 generates a different but related error.
Is this a limitation that should be mentioned in the description of
the form, or the compiler mistakienly working on something it's just
been told to ignore?
