Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
timo good good, good 07:42
lizmat indeedy indeedy indeedy ! 07:49
lizmat m: sub a(*%_) { if %_<a> -> $a { %_ } } # why is this a compilation error ? 11:31
camelia ===SORRY!=== Error while compiling <tmp>
Placeholder variable '%_' cannot override existing signature
at <tmp>:1
------> sub a(*%_) { if %_<a> ⏏-> $a { %_ } } # why is this a compilat
jnthn %_ and @_ imply placeholder signatures 11:55
m: sub a($b) { $^b } # same as this
camelia ===SORRY!=== Error while compiling <tmp>
Redeclaration of symbol '$^b' as a placeholder parameter.
at <tmp>:1
------> sub a($b) { $^b⏏ } # same as this
jnthn m: sub a($b) { $^c } # same as this
camelia ===SORRY!=== Error while compiling <tmp>
Placeholder variable '$^c' cannot override existing signature
at <tmp>:1
------> sub⏏ a($b) { $^c } # same as this
jnthn m: sub a { if %_<a> -> $a { %_ } }; say a a => 'a' 11:56
camelia ===SORRY!=== Error while compiling <tmp>
Placeholder variable '%_' cannot override existing signature
at <tmp>:1
------> sub a { if %_<a> ⏏-> $a { %_ } }; say a a => 'a'
lizmat so even if there's an outer scope %_ ?
jnthn m: sub a { if %_<a> -> $a { say $a } }; a a => 'a' 11:57
camelia a
jnthn Placeholder signatures attach to the enclosing block, and the if's block counts
lizmat m: sub a(*%_) { if %_<a> { %_ } } 11:58
camelia ( no output )
lizmat m: sub a(*%_) { if %_<a> { %_ } } ; a a => 42
camelia ( no output )
lizmat m: sub a(*%_) { if %_<a> { dd %_ } } ; a a => 42
camelia {:a(42)}
lizmat but now it doesn't ? 11:59
now it does see the outer %_ ?
jnthn Curious. No idea. :)
I'm guessing the explicit signature on the `if` is something to do with it 12:00
Also curious if RakuAST's behavior differs here
lizmat shall I make an issue for this discrepancy so that we can fix this with RakuAST ? 12:01
jnthn Well, that assumes we can decide what he semantics should be... :) 12:03
But yeah, it's a bit inconsistent
lizmat I mean. if you declare a signature on the block, and the %_ is still visible in there, there shouldn't be an inconsistency ? 12:04
jnthn m: if 42 { say $^a } 12:44
camelia 42
jnthn In that case the placeholder attaches to the enclosing block 12:45
lizmat yeah, but this was about providing a signature: 13:40
m: sub a(*%_) { if 42 -> $a { %_ } }
camelia ===SORRY!=== Error while compiling <tmp>
Placeholder variable '%_' cannot override existing signature
at <tmp>:1
------> sub a(*%_) { if 42 ⏏-> $a { %_ } }
lizmat feels to me that when the %_ is encountered, and it sees that there is a signature on the block, that it should see if there's a %_ lexically visible before throwing ? 13:41
jnthn That'd be inconsistent with other placeholder vars, though, which don't do such magic 14:07
lizmat m: { $^a; -> $b { say $a }(666) }(42) # I guess that'd be a reason you can also refer to $^a as $a ? 14:15
camelia 42
jnthn Yeah, $^a declares $a in the signature of the enclosing block 14:24
The ^ is like "declare it up there" :P 14:25
timo do we already use rakuast-based optimizer code in the rakuast branches of nqp and raku? 15:37
rakudo*
nine no
timo i seem to recall that rakuast should let us inline blocks in more cases 15:40

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!