🦋 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:03 reportable6 joined 01:03 linkable6 left, evalable6 left, evalable6 joined 01:04 linkable6 joined 06:00 reportable6 left, reportable6 joined
nine If you duplicate it, then modifications won't show up 07:13
Nemokosch Is there a language other than Perl that does this "multipart names" at all? 07:49
It rather seems like something that was never a good idea but could never hurt enough to be changed
nine Sure there are. Ruby, Python, C++ are just the ones I immediately find. 08:02
Nemokosch Where you can declare something in a namespace by naming it as if it were in a namespace? Surely not. 08:46
09:31 sena_kun joined
nine That's just a syntactic difference. The problem would still be the same. 09:41
lizmat m: class A { method a(Str:D) { } }; A.a(Str) 10:01
camelia Parameter '<anon>' of routine 'a' must be an object instance of type
'Str', not a type object of type 'Str'. Did you forget a '.new'?
in method a at <tmp> line 1
in block <unit> at <tmp> line 1
lizmat m: say Q|class A { method a(Str:D) { } }; A.a(Str)|.AST(:run)
camelia ===SORRY!=== Error while compiling
------> lass A { method a(Str:D) { } }; A.a(Str)⏏<EOL>
lizmat meh
Nemokosch Whether you allow implicit population, auto-vivification and even auto declaration of namespaces? That's more than this one problem. And I'd say yes, it would solve it. The ambiguity of "do I create a new namespace or add to an old one" would go away.
lizmat nine: looks like the :D is not being applied in signature check in RakuAST
it *is* being codegenned correctly 10:02
so looks like a QAST issue ?
hmmm.. does not appear to affect dispatch, just binding signature appears 10:05
Geth rakudo/main: 36b6244ae0 | (Elizabeth Mattijsen)++ | 4 files
RakuAST: add deparse/raku/tests for RakuAST::Type::Capture
lizmat nine: any suggestions on where to look for that? 10:21
Geth rakudo/main: 81f2ea2139 | (Elizabeth Mattijsen)++ | 3 files
RakuAST: add deparse/raku/test for RakuAST::MetaInfix::Reverse
nine lizmat: that is actually closely related to what I'm working on. C.f. my "copy the existing mess" message 11:27
lizmat nine: ack, so I won't work on that for now :) 11:28
Geth rakudo/main: fb30afaee3 | (Elizabeth Mattijsen)++ | 4 files
RakuAST: add deparse/raku/test for RakuAST::MetaInfix::Zip

Also add a RakuAST::MetaInfix marker base class to allow typechecking on any RakuAST::MetaInfix::xxx meta op (as ApplyListInfix deparsing needs to be able to differentiate on that)
11:45 ab5tract left
Geth rakudo/main: 5ff428dc0c | (Elizabeth Mattijsen)++ | 3 files
RakuAST: add deparse/raku/test for RakuAST::MetaInfix::Cross

Also simplify the .raku for all RakuAST::MetaInfix classes as these all .raku to the same structure apart from the invocant class
12:00 reportable6 left 12:02 reportable6 joined
Geth rakudo/main: e514d5d966 | (Elizabeth Mattijsen)++ | 3 files
RakuAST: add deparse/raku/test for RakuAST::MetaInfix::Hyper
rakudo/main: fb98833138 | (Elizabeth Mattijsen)++ | src/core.c/RakuAST/Raku.pm6
RakuAST: simplify many .raku methods onto generic base class handlers

Now that we have a better idea where that can be done
rakudo/main: 07d4677398 | (Elizabeth Mattijsen)++ | t/12-rakuast/TODO
RakuAST: remove some TODOs that are actually untestable base classes
16:04 japhb left 16:09 japhb joined 17:02 japhb left 17:06 japhb joined 18:00 reportable6 left 18:03 reportable6 joined
Geth rakudo/main: b258927b05 | (Elizabeth Mattijsen)++ | 3 files
RakuAST: add test for RakuAST::Regex::Backtrack::Greedy
18:39 japhb left 18:41 japhb joined 19:06 MasterDuke joined
MasterDuke t/spec/S02-literals/radix.t has a passing todo with RAKUDO_RAKUAST=1. do we have any way of specifying that in roast? or will we just wait until RAKUDO_RAKUAST is the default and un-todo it then? 19:08
[Coke] I think waiting is the easiest option 19:16
else we conditionally todo it now and then have to remove the condition later. 19:17
MasterDuke yeah, that was my assumption. just wasn't 100% sure if this had come up before 19:18
what's the rakuast equiv of `$*W.cur_lexpad()`? 19:24
nine mostly $resolver.current-scope 20:05
21:35 sena_kun left 21:39 sena_kun joined 21:40 japhb left 21:52 japhb joined 22:09 sena_kun left