Re: Multiline/embedded comments

> On 12/22/20, Vadim Belman <[email protected]> wrote:
>>
>> You interpret it incorrectly. The problem is in your '#`{' comment

On 12/23/20, Parrot Raiser <[email protected]> wrote:
> Removing the space between the #` and { changes the error message to:
>
> =3D=3D=3DSORRY!=3D=3D=3D Error while compiling /home/guru/bin/comment_tes=
t
> Couldn't find terminator } (corresponding { was at line 12)
> at /home/guru/bin/comment_test:19
> ------> <BOL>=E2=8F=8F<EOL>
>     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 defi=
nition 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...