🦋 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/rakuast-v5: bb0020077e | (Will Coleda)++ | src/Raku/Actions.nqp
convert from adhoc exception

DRAFT: Doesn't work		 00:05
rakudo: coke++ created pull request #5237:
convert from adhoc exception		 00:07
[Coke] it KIND of works, which suprises me. :) 00:08
what is $*R in RAKUAST? 00:17
nine It's the $resolver that gets passed around 08:34
[Coke]: why doesn't the old frontend need this trick? How does that manage to create the correct exception type? 08:42
lizmat m: our $a; $a := 42; dd OUR::<$a>; dd OUR::<$a>:exists 19:19
camelia Any $a = Any
Bool::True
lizmat m: our $a; $a = 42; dd OUR::<$a>; dd OUR::<$a>:exists
camelia Int $a = 42
Bool::True
lizmat either binding should work on "our" variables, or it should complain, it feels to me/ 19:20
m: say Q|our $a; $a := 42|.AST
camelia RakuAST::StatementList.new(
RakuAST::Statement::Expression.new(
expression => RakuAST::VarDeclaration::Simple.new(
scope => "our",
name => "\$a"
)
),
RakuAST::Statement::Expression.new(
expression => Raku…
lizmat m: say Q|our $a; $a := 42|.AST(:run) 19:21
camelia Cannot compile bind to RakuAST::Var::Lexical
in any IMPL-INFIX-COMPILE at src/Raku/ast/expressions.rakumod line 248
in any IMPL-EXPR-QAST at src/Raku/ast/expressions.rakumod line 731
in any IMPL-TO-QAST at src/Raku/ast/expressions.rakumod …
lizmat seems this is sorta fixed in RakuAST 19:25
[Coke] nine: the old front end cheats it in World. 21:42
er: 21:43
Sorry, in the grammar. 21:44
... I swear it was in $*W, when I did this the first time. Ok, will try again in the AST grammar, where I can avoid trigger the original adhoc error entirely.
nine: THank you, that was a good question. 21:45
vrurg [Coke]: I hit chicken-or-egg problem here. You need the CORE to use the right exception type. But the parser (either World or RakuAST) needs to know the current language before it can load the CORE. 22:16
[Coke]: Therefore, by the time when `v5` the only solution is to pre-load CORE.c where the symbol is defined. But does it worth the effort? 22:17
vrurg [Coke]: Eventually, turn out the only case where you can throw proper exception would be an EVAL _when_ it implements separate language version support for the EVAL'ed compunit. 22:19
[Coke]: And the last thing, the wrong version error happens so early that there is basically no user code to catch the exception. Its only purpose is to be reported to the console. Then why not just die? 22:21
Nemokosch there is that setting resolver thing 22:31
almost like an injector 22:32
vrurg The setting resolver would need the setting in first place. How does it know which one to load? 22:39
Once again: yes, we can pre-load CORE.c,but does it worth the efforts after all?
Nemokosch I mean, some symbols ẠRE loaded, right? Failure itself is often loaded. 22:42
just like World.nqp could resolve symbols in the old system 22:43
vrurg You miss the _key_ point: when `use vX` is parsed – it's the FIRST statement in a compunit. Nothing is loaded by then. Just plain nothing. 23:14
Core setting is loaded only when we know compunit's version – i.e. no earlier than `use vX`, no later than the first non-version statement is encountered. 23:15
Nemokosch I'd say what I miss is why all this matters now 23:17
why is this suddenly the key? what is the goal?

Powered by Cro and the Raku® Programming Language.

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

Thank you!