🦋 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.
00:00 reportable6 left 00:02 reportable6 joined 06:00 reportable6 left 06:02 reportable6 joined
Geth rakudo/main: 5d7e385777 | (Elizabeth Mattijsen)++ | src/core.c/Exception.pm6
Remove support for PERL6_EXCEPTIONS_HANDLER

This was supposed to have been removed from 2020.11 already		 08:48
rakudo/main: f49b108041 | (Stefan Seifert)++ | 3 files
RakuAST: throw correct exception type on redeclaration of packages
 09:19
rakudo/main: 3f7deafbcd | (Stefan Seifert)++ | src/Raku/Grammar.nqp
RakuAST: restore correct exception on unknown type in declaration
rakudo/main: 46a99d1863 | (Stefan Seifert)++ | src/Raku/ast/variable-access.rakumod
RakuAST: properly report undeclared &-sigiled variables

These must be reported as unknown routines.		 10:07
rakudo/main: 610bcfaf0f | (Stefan Seifert)++ | src/Raku/ast/signature.rakumod
RakuAST: fix IMPL-HAS-PARAMETER stumbling over targetless parameters
 11:24
rakudo/main: 9406dfe9fb | (Stefan Seifert)++ | src/Raku/ast/code.rakumod
RakuAST: fix duplicate lexical $_ in pointy blocks with explicit $_ arg
lizmat 716/1355 ! 11:47
12:00 reportable6 left 12:01 reportable6 joined
Geth rakudo/main: c9987b7c4d | (Elizabeth Mattijsen)++ | 2 files
Actually add type info to constant declaration

And make sure any errors are correctly reported		 12:06
lizmat ^^ nine is there a reason why the type check can't live in the BEGIN-CHECK ?
or shouldn't live there ? 12:07
nine Why should it? 12:10
lizmat to be able to proved feedback earlier ?
*prove
*provide 12:11
nine That's actually not considered a good thing
In general, any correctness checks should be done as late as possible. This gives e.g. macros the chance to do something about issues first. 12:13
lizmat ah, good point. understood
nine Also with late checks we can collect multiple issues we find and give a more complete list of errors. That can be a bit of a double edged sword, if one error is actually the cause of the other, but in general it's nice to have. 12:14
Geth rakudo/main: c487eb152e | (Elizabeth Mattijsen)++ | 2 files
RakuAST: add test for RakuAST::Var::Lexical::Constant
 12:30
rakudo/main: bc24e6f222 | (Stefan Seifert)++ | src/Raku/ast/literals.rakumod
RakuAST: Fix pairs in quotewords getting stringified when they shouldn't
 12:48
rakudo/main: 79ec334ea9 | (Stefan Seifert)++ | 2 files
RakuAST: fix \n, \r\n, \t in heredocs disturbing detentation

When detenting heredocs, we need to treat explicit \n, \r\n and \t as opaque strings, i.e. we need to ignore the newline in foo\nbar
13:01 linkable6 left, evalable6 left 13:02 evalable6 joined 13:03 linkable6 joined
Geth rakudo/main: ac217e866f | (Stefan Seifert)++ | src/Raku/ast/name.rakumod
RakuAST: fix without-colonpairs stumbling over QuotedString

Fixes regression caused by e8f419aefb716e2e89b098662cbed01fc3ec3bbd		 13:08
nine Wowser....this ^^^ regression affected a lot more than expected. 13:09
lizmat nice! meanwhile, I just notice that {*} as part of a statement list, is parsed as { * } 13:11
which is *not* the same, and thus blocks re-dispatching from non-simple protos
perhaps some LHF for you? 13:12
nine ^^
nine Which test file does this affect?
lizmat I don't know, I was just looking at .raku and .DEPARSE of {*} 13:13
and found that {*} in a statement list didn't trigger
725/1355 ! 13:17
nine Like I said...quite unexpected how effective that regression fix is :) Since the spectest run I do after every commit didn't flag it, that means that the fixes since e8f419aefb716 were better than expected 13:19
13:19 linkable6 left 13:22 linkable6 joined
nine lizmat: that {*} thing sounds easy: just look for that string in the old grammar and check if the new one handles it in the same places. Probably just missing one 13:37
lizmat ok, will do 13:38
so far, only macro_def appears missing.... 13:47
BTW, do we plan to support old macro behaviour in RakuAST ? 13:48
nine So we already parse it. What exactly do we parse it to? 13:53
lizmat a block with a statement list with a whatever in it 13:54
as if it was "{ * }" instead of {*} 13:55
"{*}"
nine Huh....I wonder how the old frontend dealt with the onlystar in a statement list if not in the parser 13:58
lizmat in the case of Moar, it looks like the Grammar actually writes out the QAST immediately 13:59
line 4199 in Perl6/Grammar 14:00
afk& 14:01
nine You mean in Perl6/Actions? 14:04
No, there is a difference in the grammars: Raku::Grammar is missing the token term:sym<onlystar> 14:08
That's "onlystar in term position"
Geth rakudo/main: 525dd64384 | (Stefan Seifert)++ | src/Raku/Actions.nqp
RakuAST: fix our scoped names not found lexically

Our-scoped does not mean "only our-scoped". Even for our-scoped symbols, we always create a lexical alias.		 14:23
rakudo/main: 5a869366e9 | (Stefan Seifert)++ | 2 files
RakuAST: support {*} in term position

This is enough to support re-dispatch from protos to the multi, e.g. proto foo(|) { say "before"; {*}; say "after"}
nine lizmat: ^^^
that's 2 more :)
lizmat cool! 15:13
Geth rakudo/main: 6 commits pushed by (Elizabeth Mattijsen)++ 15:28
lizmat nine: I wonder whether it wouldn't make sense to create a separate RakuAST::Signature object for (|) 15:35
nine why? 15:42
lizmat it now is a whole Signator -> parameters -> Parameter(type, names, captures, slurpy) thing 15:44
that needs to be deciphered when making the AST for not doing anything basically ?
nine But (|) _is_ a signature. And it does have one Parameter which is a capture 15:46
lizmat *Signature
yeah, but at QAST level it has different handling, no ?
nine Different how? 15:51
lizmat just look at the qast that "sub a (|c) { }" and "sub a (|) { }" generate on the Perl6 grammar 15:54
nine And "sub a ($c) { }" will yet again produce different qast. I fail to see what makes (|) so special that we'd put it in its own class? 15:56
lizmat so we wouldn't need to introspects the Signature -> Parameter -> type/name/etc to figure out it's a noop 16:00
when producing the qast ?
nine You'll need to check for that condition somewhere. Either when producing the QAST or when producing the AST. Only that in the latter case, every user who wants to assemble RakuAST manually will have to know about this mandatory check as well. 16:01
The goal of RakuAST is not to be the most efficient representation of the program or the the fastest compiler frontend. It's to be a correct and semantically rich representation which lends itself to manipulation (including the important subset of optimization). Making the compiler faster will (hopefully) be a side-effect. 16:04
lizmat sure, but (|) is effectively about *not* creating a Capture object, and now we need to specify it as creating a nameless Capture object ? 16:19
fwiw, I've always seen (|) more as a "trait" than actually as a signature 16:20
but I guess otoh, you could think of not creating a nameless Capture to be an optimization
still it feels LTAish to me
nine It _is_ an optimization. Nothing is broken by doing exactly what the signature says, i.e.creating a Capture. 16:39
17:46 linkable6 left, evalable6 left 17:48 evalable6 joined 17:49 linkable6 joined
Geth rakudo/main: 5787c4f631 | (Elizabeth Mattijsen)++ | src/Raku/ast/signature.rakumod
RakuAST: only wrap when *not* given a parameters List

Because if it *is* specified, it is already a List		 17:50
18:00 reportable6 left 18:01 reportable6 joined
Geth rakudo/main: 13c2bade8f | (Stefan Seifert)++ | src/Raku/ast/code.rakumod
RakuAST: fix "No such method 'IMPL-CURRIED' for invocant of type 'RakuAST::OnlyStar'"

Since OnlyStar can now appear in term position, it must be a Term		 18:04
rakudo/main: 9c03075459 | (Stefan Seifert)++ | 3 files
RakuAST: report redeclarations of lexicals as compilation errors
18:05 vrurg_ joined, vrurg left 18:24 linkable6 left 18:27 linkable6 joined
Geth rakudo/main: 2a5220a5f9 | (Elizabeth Mattijsen)++ | src/Raku/ast/code.rakumod
RakuAST: Onlystar doesn't actually need statements

In fact, I wonder whether this class should be instantiated at all and whether it should be a Blockoid. Feels to me it could be a standalone class, just like RakuAST::Statement::Elsif		 18:54
19:38 vrurg_ left 19:39 vrurg joined
nine lizmat: it can only be a routine's body if it's a Blockoid 19:46
lizmat yeah, tested that already :-) 19:47
nine: now that I have you on the horn 19:48
if I create a multi sub using RakuAST:: calls, the proto should be made automatically 19:49
it *is* when coming from the grammar
but in a test file, it fails because $resolver.resolve-lexical($name) resolves (when it shouldn't)
to a RakuAST::Declaration::External object 19:50
which cannot do: $proto.compile-time-value.derive_dispatcher
easy solution would be to wrap it in a try() 19:51
but that feels meh
line 1283 and following in ast/code
lizmat gives up for now 19:54
afk&
nine Does that happen in a golfed case? 20:16
Geth roast: patrickbkr++ created pull request #833:
Test supply setup with a blocking recursion		 21:51

Powered by Cro and the Raku® Programming Language.

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

Thank you!