🦋 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/main: f3f31de633 | (Daniel Green)++ | src/Raku/ast/variable-declaration.rakumod
RakuAST: throw for '!' vars in 'my' | 'our' | 'state' scope

So e.g., `role A { my $!foo }` now throws `X::Syntax::Variable::Twigil`.
No new spectest files pass, but fixes one of the two failing tests in t/spec/6.c/S14-roles/mixin-6c.t.		 06:54
rakudo/main: e524c0438c | niner++ (committed using GitHub Web editor) | src/Raku/ast/variable-declaration.rakumod
Merge pull request #5816 from MasterDuke17/rakuast_fail_for_private_vars_in_my_or_our_or_state_scope

RakuAST: throw for '!' vars in 'my' | 'our' | 'state' scope		 06:55
lizmat nine: golfed final error in t/spec/APPENDICES/A01-limits/misc.t to gist.github.com/lizmat/28ae4ee61f0...56b61a19af 10:23
looks like the consumption of a role changes its outer lexical scope 10:24
perhaps that rings an immediate bell with you ? 10:27
nine lizmat: better golf: my $a = "NOT set"; sub a() { $a = "set" }; BEGIN a(); say $a; 10:44
But here's the kicker: 10:45
m: my $a = "NOT set"; sub a() { $a = "set" }; BEGIN a(); say $a;
camelia NOT set
nine Same with:
m: my $a = "NOT set"; role Foo { $a = "set" }; class Bar does Foo { }; say $a;
camelia NOT set
lizmat so this issue was known to you already 10:46
aka the compile time outer is different from the runtime outer scope?
nine No, just golfed it further. But it's really a bug in that code. Think about when BEGIN really runs. 10:47
It does so before $a is initialized with "NOT set";
So the fix to your golf is: BEGIN my $a = "NOT set"; role A { method a($ where { say "in where"; dd $a; $a = "set" }) { dd } }; class B does A { }; A.new.a(2); say $a;
lizmat that would imply the test is faulty 10:48
hmmm otoh, without RakuAST it does work... 10:49
without the BEGIN, and also with optimization switched off 10:51
nine On the other hand the A.new.a is at runtime and definitely after $a is initialized. 10:55
What definitely happens at BEGIN time is dynamic compilation of that method. 10:56
lizmat I just don't understand why it works in the legacy grammar
nine It's World's compile_in_context vs. IMPL-COMPILE-DYNAMICALLY 10:58
lizmat so the latter is missing: 11:00
Create outer lexical contexts with all symbols visible. Maybe
# we can be a bit smarter here some day. But for now we just make a
# single frame and copy all the visible things into it.
?
nine It's not missing that. We take a different approach with self.IMPL-FIXUP-DYNAMICALLY-COMPILED-BLOCK 11:01
JimmyZhuo m: my Str @AoS = <a b>; 11:11
camelia ( no output )
Geth rakudo/main: b12b45b52e | (Stefan Seifert)++ | src/Raku/ast/package.rakumod
RakuAST: don't add role stubs to their role groups

Normally when a package is stubbed, the generated meta-object is later re-used when the package is fully defined. This ensures that any lookups done between stubbing and defining ultimately resolve to the meta object that is fully defined.
... (10 more lines)		 11:14
rakudo/main: d02dd8e36e | (Stefan Seifert)++ | src/Raku/ast/code.rakumod
RakuAST: fix our scoped proto methods missing from their package

Fixes: my class Dummy { our proto method foo() { } }; dd &Dummy::foo
nine 1078 fully bootstrapped (because it fixed auto-generation of proto methods)
lizmat coming back to my gist 11:16
I still don't grok why initializing $a at BEGIN time would fix the issue 11:17
as the method is called at runtime
*after* $a got initialized
and the where block is also called at runtime afaics 11:18
nine $a in that where block no longer refers to the lexical defined in the outer scope. Actually it never did because that scope (and thus the lexical) didn't even exist yet when the method was compiled. The old frontend fakes up a frame containing all lexically visible symbols and uses that as outer. 11:22
In RakuAST we instead resolve all symbols at compile time and replace e.g. a QAST::Var(:scope<lexical>) with a QAST::WVal holding the compile tiem value 11:23
lizmat so the test is faulty / or needs changing
nine not sure about that
While neither the scope nor the lexical will exist yet, the container that eventually gets bound to it does. 11:25
m: 'my $a; BEGIN $a = 1; say $a'.AST.EVAL 11:26
camelia ===SORRY!===
Unknown compilation input 'qast'
nine That's why this ^^^ works at all (ignoring that EVAL issue) 11:27
lizmat well, the test appears to be about determining the order in which candidates are run, so I can change the test using a dynvar 11:29
Geth roast: c473f3ceac | (Elizabeth Mattijsen)++ | APPENDICES/A01-limits/misc.t
Fix test checking candidate checking order

Accessing lexicals from within where blocks is not guaranteed to work. So use a dynvar to do the checking, rather than a lexical.		 11:32
lizmat that's +1 for RakuAST :-)
nine But that just sweeps a problem under the rug 11:33
lizmat the test was not about this issue... and it already mentioned it was using unsupported features to make the test 11:34
I mean, isn't that similar to incorrectly thinking that classes are closure clones? 11:36
nine This reproduces the same problem without using unsupported where clause side effects: my $a = "NOT set"; role Foo { method foo() { $a = "set" } }; class Bar does Foo { }; Foo.new.foo; say $a; 11:41
lizmat ok, then I'll add a test for that 11:44
Geth roast: 0398c33174 | (Elizabeth Mattijsen)++ | 6.c/S14-roles/mixin-6c.t
Add test for accesing outer lexicals in role
 12:24
rakudo: zhuomingliang++ created pull request #5817:
improve type check, there still a lot of improvement		 12:26
nine is afk for a few hours 12:40
Geth roast: dca7e75327 | (Jimmy Zhuo)++ | 2 files
change runtime error to compiling error
 13:20
JimmyZhuo hmm, t/spec/S17-promise/nonblocking-await.t and t/spec/S17-procasync/many-processes-no-close-stdin.t sometimes failed 13:43
MasterDuke m: q|say pi()|.EVAL; CATCH { dd $_ } 14:00
camelia X::Undeclared.new(what => "Variable", symbol => "\&pi", suggestions => [], pos => Any, filename => "EVAL_0", line => 1, directive-filename => Any, column => Any, modules => [], is-compile-time => Bool::True, pre => "say ", post => "pi()", highexpect =…
tellable6 hey MasterDuke, you have a message: gist.github.com/9edafe8329124e982b...08ec1715a6
MasterDuke m: q|say pi()|.AST.EVAL; CATCH { dd $_ }
camelia X::Undeclared::Symbols.new(post_types => {}, unk_types => {}, unk_routines => {:pi($(1,))}, routine_suggestion => {:pi($( ))}, type_suggestion => {}, pos => Any, filename => "EVAL_0", line => Any, directive-filename => Any, column => Any, modules => […
MasterDuke this is why a couple spectests fail. `X::Undeclared::Symbols` isn't a subclass of `X::Undeclared` 14:01
however, i like the error message from the RakuAST version better 14:02
`Variable '&pi' is not declared.  Perhaps you forgot a 'sub' if this was intended to be part of a signature?` from legacy vs `Undeclared routine: pi used at line 1` from RakuAST 14:03
lizmat hmmm: No such method 'add-worry' for invocant of type 15:11
'RakuAST::Resolver::EVAL'
which is weird, as that inherits from RakuAST::Resolver, and that *has* an "add-worry"
m: class A { method TWEAK { dd } }; class B is A { }; B.new # I wonder this is a bug 15:41
camelia method TWEAK(A $:: *%_)
method TWEAK(A $:: *%_)
lizmat yes, I understand that you should make it a submethod if you don't want that
but why is it callled twice ?? 15:42
Geth roast/master: 4 commits pushed by (Daniel Green)++, MasterDuke17++ 16:57
MasterDuke huh. why doesn't `try self.actions.r('EXPERIMENTAL-' ~ nqp::uc($feature))` succeed when `$feature` eq 'MACROS' in src/Raku/Grammar.nqp? 20:12
nine That's actually the reason why my reported numbers are a bit higher: I have a local change in t/spec changing that X::Undeclared into X::Undeclared::Symbols 20:13
MasterDuke ha, nice 20:14
MasterDuke can't find EXPERIMENTAL-PACK either 20:48
both are defined in lib/experimental.rakumod 20:50
timo was pack thrown out? 20:53
m: use experimental :pack;
camelia ( no output )
timo guess not 20:54
MasterDuke i thought maybe i could try implementing some of the grammar to recognize macros, but pretty sure i don't want to get into having to deal with exporting symbols and such 20:57
timo i'm gonna try making a better reproducer for gh1201 based on a fresh theory i just developed 22:31
[Coke] I wouldn't do anything with macros with the non-RakuAST impl. 23:12
timo i think he was suggesting to work on the rakuast bits related to macros? 23:13
[Coke] ah 23:14

Powered by Cro and the Raku® Programming Language.

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

Thank you!