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?
>
Re: Diagnostics?
If you think this is a bug you're always welcome to open a ticket at
https://github.com/rakudo/rakudo/issues. Even if it eventually would turn out
to be not a bug that wouldn't hurt anybody.
In either case it would be very welcomed to always include examples paired with
output.
Best regards,
Vadim Belman
> On Jul 8, 2019, at 11:42 AM, Parrot Raiser <1parr...@gmail.com> wrote:
>
> I've been fiddling with multi-line comments and the bounding
> characters. Naturally-paired characters e.g. #`(...) #`[...] #`{...}
> all work well, but with other boundary characters like #`@@ or
> #`!! produce odd, displaced, diagnostic messages. Reproducing them
> is so easy, I'll leave it as "an exercise for the reader".
>
> If unpaired boundary characters like these are legal, presumably
> there's a problem with the parser or compiler?
> If they aren't, maybe a) the docs should be more explicit, and b), the
> diagnostics should say so, immediately?
>
> perl6 -v
> This is Rakudo Star version 2019.03.1 built on MoarVM version 2019.03
>
Submethods in roles
Hello,
I'm working on a fix for https://github.com/rakudo/rakudo/issues/2250. While
the problem itself is easily tracks down to add_method not reporting a error,
the general fix requires clear understanding of what happens to submethods when
a role consumes another role. While things are pretty straightforward for
methods, which are copied over from the source role to the target, for
submethods not everything is so clear as I see it. Let's consider the following
setup:
role R1 { submethod foo { "R1::foo" } }
role R2 does R1 { }
class Foo does R2 { submethod foo { "Foo::foo" } }
Imagine a code which would like to execute all submethods of all classes and
roles. Normally, it would traverse mro and all role concretizations of each
class from mro. In the example above such code would call submethod foo() from
R1 twice: for R2 and R1 itself! Of course, there is a workaround for this as
foo from R1 will have its .package set to R1. But what sense does such copying
makes? When a role gets applied to class it does make some sense when we talk
about BUILD/TWEAK/DESTROY. Though if
https://github.com/rakudo/rakudo/issues/2241 gets implemented then even this
use case will be obsoleted.
So, to have a comprehensive fix for #2250 I need to know how to handle
submethods when a role is applied to a role: either I leave them untouched
where they're (and this would be my choice); or I get them copied alongside
with methods.
Best regards,
Vadim Belman
