🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm
Set by lizmat on 8 June 2022.
Geth rakudo: MasterDuke17++ created pull request #5808:
RakuAST: warn for duplicate traits		 01:59
rakudo: zhuomingliang++ created pull request #5809:
add X::Parameter::WrongOrder exception to wrong order parameters		 03:30
Geth rakudo/main: 0cd87d3ee2 | (Daniel Green)++ | src/Raku/ast/traits.rakumod
RakuAST: warn for duplicate traits

Now `sub foo is raw is raw {}` will warn:
Potential difficulties:
   Duplicate 'is raw' trait
   at line		 07:42
rakudo/main: 91c98a2e25 | niner++ (committed using GitHub Web editor) | src/Raku/ast/traits.rakumod
Merge pull request #5808 from MasterDuke17/warn_for_duplicate_traits

RakuAST: warn for duplicate traits
Geth rakudo/main: f0913170f6 | (Jimmy Zhuo)++ | src/Raku/ast/signature.rakumod
add X::Parameter::WrongOrder exception to wrong order parameters
 09:09
rakudo/main: dc47d51c46 | niner++ (committed using GitHub Web editor) | src/Raku/ast/signature.rakumod
Merge pull request #5809 from zhuomingliang/WrongOrder

add X::Parameter::WrongOrder exception to wrong order parameters
nine I am working on this bizarre problem: 10:14
> RAKUDO_RAKUAST=1 ./rakudo-m --ll-exception -e 'multi foo($s) { say "str" }; multi foo("1") { say 1 }; foo("5")'
str
So, fine, but:
> RAKUDO_RAKUAST=1 ./rakudo-m --ll-exception -e 'multi foo($s) { say "str" }; multi foo("1") { say 1 }; BEGIN foo("5")' 10:15
Constraint type check failed in binding to parameter '<anon>'; expected "1" but got "5"
Can't find why multi dispatch makes the wrong decision at BEGIN time but is fine at runtime. I have looked at the QAST generated for foo and it's identical in both cases. That means there must be a difference in meta data. But I can't find any either. 10:16
Parameter flags are just 128 for that literal parameter. signature gists look identical.
And of course the proto has both candidates 10:17
lizmat needs to update rakudo first :-) 10:22
lizmat nine: fwiw, I get this error: 10:25
No such method 'compile-time-value' for invocant of type
'RakuAST::VarDeclaration::Implicit::Block'
another thing: I just found this discrepancy, not sure what to make of it: 10:28
m: say Q|now|.AST.statements.head.expression
camelia RakuAST::Term::Named.new("now")
lizmat m: say Q|False|.AST.statements.head.expression
camelia RakuAST::Term::Name.new(
RakuAST::Name.from-identifier("False")
)
lizmat why aren't both ::Named or both ::Name ? 10:29
Geth rakudo/main: 7b093be2b1 | (Stefan Seifert)++ | src/Raku/ast/code.rakumod
RakuAST: fix No such method 'compile-time-value' on BEGIN with subs in scope

Fixes: sub foo() { }; BEGIN say "hi"		 10:36
nine lizmat: ^^^
I'd say the comments above class RakuAST::Term::Name and RakuAST::Term::Named explain the difference 10:37
lizmat ok, that explains their origin. Not sure they should be treated different at tree level 10:40
but that's for later :-)
I was just struck by the different handling just now 10:41
nine Btw can you check whether that latest commit regresses spec tests? It does so for me with t/spec/S04-declarations/will.rakudo.moar t/spec/S06-multi/compile-time.t or t/spec/S16-io/home.t but when I run them individually they're just fine
lizmat fwiw I now get the same error that you say for the BEGIN dispatch issue 10:42
checking spectest now
JimmyZhuo m: sub foo(Int $x = "omg") { } 10:45
camelia ===SORRY!=== Error while compiling <tmp>
Default value 'omg' will never bind to a parameter of type Int
at <tmp>:1
------> sub foo(Int $x = "omg"<HERE>) { }
expecting any of:
constraint
lizmat nine: yeah, got quite a few regressions 10:49
t/spec/S04-declarations/will.rakudo.moar apears to be a flapper, as it runs fine on its own 10:50
I do get:
WARNING: unhandled Failure detected in DESTROY. If you meant to ignore it, you can mark it as handled by calling .Bool, .so, .not, or .defined methods. The Failure was:
Stub code executed
in any IMPL-BEGIN-TIME-CALL at src/Raku/ast/begintime.rakumod line 56 10:51
t/spec/S06-advanced/stub.rakudo.moar also flaps
as does t/spec/S06-multi/compile-time.t
as does t/spec/S06-signature/introspection.rakudo.moar 10:52
t/spec/S16-io/home.t fails with: No such method 'CALL-ME' for invocant of type 'Mu'
Geth rakudo/main: c77434ad24 | (Stefan Seifert)++ | src/Raku/ast/code.rakumod
RakuAST: better fix for No such method compile-time-value

Honestly no idea why the previous version caused the strange regressions.		 11:06
nine Ok, this distraction is hopefully out of the way
No back to the bizarre dispatch problem
lizmat notable6: weeklly 12:23
notable6 lizmat, No notes for “weeklly”
lizmat notable6: weekly
notable6 lizmat, 2 notes: 2025-03-03T21:15:41Z <antononcube>: rakuforprediction.wordpress.com/20...xtensions/ ; 2025-03-06T15:34:00Z <antononcube>: rakuforprediction.wordpress.com/20...ns-graphs/
lizmat notable6: weekly reset
notable6 lizmat, Moved existing notes to “weekly_2025-03-10T12:23:44Z”
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2025/03/10/2025-...-cfp-week/ 13:07
nine Oh, the first real lead! 13:34
nine@sphinx:~/rakudo.main (main <>)> RAKUDO_RAKUAST=1 ./rakudo-m --ll-exception -e 'proto foo(|c) {*}; multi foo($s) { "str" }; multi foo("1") { 1 }; BEGIN foo("1"); BEGIN foo("5")' 13:35
nine@sphinx:~/rakudo.main (main <>)> RAKUDO_RAKUAST=1 ./rakudo-m --ll-exception -e 'proto foo(|c) {*}; multi foo($s) { "str" }; multi foo("1") { 1 }; BEGIN foo("5")'
Constraint type check failed in binding to parameter '<anon>'; expected "1" but got "5"
And a fix! 13:40
Geth rakudo/main: 70fd1bfaf9 | (Stefan Seifert)++ | src/Raku/ast/code.rakumod
RakuAST: fix bind failures in BEGIN time multi-dispatch

The multi-dispatcher wants to force compilation of a not-yet fully compiled routine before trying the bind-check. This is so that the compiler's call frames don't interfere with the dispatch resumtion. The RakuAST frontend however neglected to give it a way to do so.
Fixes: multi foo(1) { }; multi foo(Int $a) { }; BEGIN foo(2);		 13:45
nine Even fixes a spectest so we're now at 1275
Ironically compilation now fails in RakuAST related setting code 13:51
'class Foo { has $.generator; submethod BUILD() { $!generator = BEGIN -> { say self } } }; Foo.new.generator.()'.AST.EVAL 13:54
m: 'class Foo { has $.generator; submethod BUILD() { $!generator = BEGIN -> { say self } } }; Foo.new.generator.()'.AST.EVAL
camelia ===SORRY!===
Symbol 'self' does not have a compile-time value
nine m: class Foo { ... } 16:11
camelia The following packages were stubbed but not defined:
Foo
nine m: role Foo { ... }
camelia ( no output )
nine Huh? 16:11
Looks like we don't care at all about stubbed but undefined roles 16:12
Geth rakudo/main: 6224971e72 | (Stefan Seifert)++ | src/Raku/ast/package.rakumod
RakuAST: don't complain about stubbed but undefined roles

No idea why. The old frontend didn't either and this gets around a problem with multi-part names.		 16:19
Geth rakudo/main: 45c4f74f87 | (Stefan Seifert)++ | src/Raku/ast/variable-declaration.rakumod
RakuAST: skip type check on native constants

Would only fail.
Fixes: my int constant $i = 1;		 16:55
lizmat m: role A { ... } 17:04
camelia ( no output )
lizmat m: role A { ... }; class B does A { }
camelia ===SORRY!=== Error while compiling <tmp>
No appropriate parametric role variant available for 'A':
Cannot resolve caller (B); Routine does not have any candidates. Is only the proto defined?
at <tmp>:1
lizmat hmmm... that's LTA ?
I mean, I get it that we don't complain about stubbed roles 17:05
in a way, it's similar to:
m: sub a() { ... }
camelia ( no output )
lizmat m: sub a() { ... }; a
camelia Stub code executed
in sub a at <tmp> line 1
in block <unit> at <tmp> line 1
lizmat and since the body of a role is essentially a sub with the parameterization as arguments... 17:06
nine Why complain about classes then? 17:07
lizmat actually, I think we should worry about stubbed roles
Geth rakudo/main: fa865469d2 | (Stefan Seifert)++ | src/Raku/ast/statements.rakumod
RakuAST: fix copy pasta in check for multiple CATCH/CONTROL blocks

Fixes: CATCH { }; CONTROL { }		 17:08
nine m: sub foo(*%_) { -> { %_ } } 17:18
camelia ===SORRY!=== Error while compiling <tmp>
Placeholder variable '%_' cannot override existing signature
at <tmp>:1
------> sub foo(*%_) { <HERE>-> { %_ } }
nine but:
m: my method foo() { -> { %_ } }
camelia ( no output )
nine even: 17:19
m: my method foo(*%_) { -> { %_ } }
camelia ( no output )
lizmat there are many variations on this theme, afaik
nine The joy of a language where stuff just magically appears. But I guess you just have to learn from the winners, like PHP. 17:22
jdv oh my, php:) 17:23
my last full time gig was mostly php for 5y. 17:24
lizmat fwiw, I think the automatic adding of *%_ methods, has been a msitake 17:26
*error :-)
nine As is checking for declarations of @_ and %_ only in the immediate surrounding block 17:29
Geth rakudo/main: 9f1fff2f45 | (Stefan Seifert)++ | src/Raku/ast/code.rakumod
RakuAST: always give placeholder parameters their begin time

Fixes compiler error in: my method foo() { -> { %_ }() }		 17:54
Geth rakudo/main: 7f6af8e4bd | (Stefan Seifert)++ | 2 files
RakuAST: fix bogus complaint about placeholder parameters

There's a %_ if we're inside a method, regardless of how many blocks deep.
Fixes: my method foo() { -> { %_ } }		 18:50
rakudo/main: c1eead8776 | (Stefan Seifert)++ | src/Raku/ast/signature.rakumod
RakuAST: thunk parameters default value at BEGIN time

We should keep CHECK time for actual checks and not rely on CHECK time for anything that influences the compilation result.		 18:57
nine Aw man... RakuAST::Var::Attribute::Public should really have become a RakuAST::Expression instead of pretending to be one 19:04
lizmat why not change ? 19:05
nine Exhaustion
Actually I think it shouldn't even exist 19:06
lizmat RakuAST::Var::Attribute::Public ? 19:09
nine yes 19:10
lizmat well, I guess it exists because $.foo attribute accesses get an .item called in it, where as $!foo accesses do not ? 19:11
(and .list for @ and .hash for % sigilled attributes)
couldn't we get rid of that class and handle it in the actions ? 19:12
nine That's exactly what we did before you replaced that with the class :) 19:18
lizmat ok, we learn from our mistakes? 19:21
ah, I see 527b9788d9 19:23
linkable6 (2024-07-16) github.com/rakudo/rakudo/commit/527b9788d9 RakuAST: introduce ::Var::Attribute::Public
lizmat deparsing and manual creation as reasons 19:24
manual creation reason could be done in RakuAST::Utils
deparsing I'm not too sure about we want to break
nine Break in what way? 19:25
Stage parse : 35.347 19:26
Stage syntaxcheck: 0.000
Stage ast : 0.000
lizmat m: say Q|class A { my method a() { $.foo } }|.AST.DEPARSE
camelia class A {
my method a () {
$.foo
}
}
nine We make it through parsing and checking! 19:27
lizmat whee!
and how much slower is the stage parse for you ?
also: perhaps switch of stage optimize for now? 19:28
the deparse would become: self.foo.item
nine It's about 20 % slower than the old frontend. Which sounds like a great start to me considering that performance of compilation wasn't really a priority 19:29
lizmat re: RakuAST::Var::Attribute::Public: would s/is RakuAST::Node/isis RakuAST::Expression/ ??
be a solution for your problem? 19:30
20%! pretty good
nine Probably yes. Though I still don't see why it needs to exist at all. After all $.foo *is* exactly self.foo.item 19:31
lizmat most users don't realize that: they just think of $.foo as a subclass safe way of accessing the $!foo attribute / method
ah: another reason to keep it: if $.foo is interpolated in a string, deparsing would become really troubles if that class is removed 19:32
nine Nobody says that self.foo.item HAS to deparse as exactly that 19:33
In a string using the $.foo form makes more sense. After all I'm pretty sure that's what it was invented for
What does +$ mean in a parameter like in multi sub infix:<orelse>(+$)? 20:02
timo it's a special kind of slurpy, but i thought those were supposed to go with @ and not $ 20:05
it's like * but implements "single argument rule" semantics, right? 20:06
nine That's +@ 20:18
timo i thought +$ is just "+@ but wrongly generalized" 20:39
nine Yeah looks like it's equivalent to +@ 20:54
76 % through stage QAST now. Qualified private method calls NYI 21:25
[Coke] nine++ 21:50
MasterDuke i'm not sure where to address t/spec/S06-signature/positional-placeholders.t. this is an example failing test `{my $foo; $^foo;}(1)`, it's supposed to throw X::Redeclaration, but currently it's just an X::AdHoc from NQP with `RAKUDO_RAKUAST=1` 23:47
lizmat that's because that condition wasn't spotted before it was handed over to NQP: I guess the former is a compile time error, and the latter is runtime ? 23:49
MasterDuke but i can't figure out if i should be adding a check in src/Raku/Actions.nqp, or src/Raku/ast/resolver.rakumod, or src/Raku/ast/variable-declaration.rakumod
lizmat feels to me in variable-declaration
but then it's late for me and I really should hit the sack :-) 23:50
&
MasterDuke later...

Powered by Cro and the Raku® Programming Language.

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

Thank you!