> On 12/22/20, Vadim Belman <vr...@lflat.org> 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
> ------> <BOL>⏏<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
> 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...
