🦋 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:21 MasterDuke joined 01:29 nine left 01:30 nine joined
nine Well I do try to avoid Pareto by fixing tests indiscriminately, i.e. I have never looked for low hanging fruit and instead go throug them in alphabetic order. Thus the remaining ones should be about as hard as the past ones. 05:25
05:29 sjn left 05:34 sjn joined 06:29 MasterDuke left
ab5tract I hadn’t thought of Pareto as something that could be influenced in that way, though it makes sense because I’ve seen plenty of people try to get away with gaining 80% of Outcome from 20% of Input 07:34
Regardless, it’s really great to see RakuAST in momentum mode again :) 07:36
07:48 Geth joined, lizmat_ left, lizmat joined
Geth nqp/main: 70db49669a | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump MoarVM for faster hashification of in situ strings

  MasterDuke++		 10:23
rakudo/main: 1cfdd167e4 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP for faster hashification of in situ strings

  MasterDuke++		 10:35
nine Huh....the deparse stuff has become a lot more complicated 10:59
lizmat nine: working on that now, no worries, focus on other things 11:10
I'm taking care of the test failures atm
sorry, I thought you'd taken last night's hint :-)
nine: re interface, perhaps the use of these classes should be more hidden 11:17
aka: :dispatch<safe>, :dispatch<all>, :dispatch<any> 11:19
?
nine Maybe. Originally I thought they would contain more logic 11:20
lizmat ok, if I rewrite that part to such and interface? 11:21
also: would these classes need to be instantiated at all ?
nine Probably not. It just makes it easier to detect whether a special dispatch is selected 11:22
lizmat instantiating it ? 11:23
ah you mean, compared to the default dispatch 11:24
nine yes
lizmat hmmm... an nqp::eqaddr($dispatch,RakuAST::MethodDispatch) instead of an nqp::isconcrete() ? 11:28
nine: also feels to me the $!dispatch attribute and dispatch accepting logic should be moved to Methodish role 11:46
nine Not all Methodish classes support non-standard dispatch 11:47
lizmat ah, yes, so a separate role then
nine Is it worth that? 11:51
lizmat for maintainability, I'd say yes 11:56
nine: OOC, with a DOTTY of .&, how can a VarMethod be anything but MethodDispatch (aka how can it not be the default?) 12:26
nine Well it can be .+&foo 12:33
VarMethod also covers .$foo
lizmat hmmm then it feels we have a logic issue on Actions::methodop 12:37
because we check for DOTTY .? .+ .* first to set $dispatch 12:38
and then later we test for .& for VarMethod
ok, I'll figure that out... after some lunch 12:39
nine huh
lizmat well, in case of a longname 12:40
nine I wish the whole translation stuff were implemented less invasively. It makes the grammar, which is already a dense piece of code even less readable 12:50
12:58 finanalyst joined
lizmat nine: I'm open to suggestions 12:59
nine Maybe as subclass or via delegation 13:00
The highlight stuff looks like a great case for meta programming. After all, you just need to wrap the generated strings in color codes, i.e. wrap those methods 13:02
lizmat fwiw, highlighting goes a little further than just colors 13:10
I also see use for it for tooltip highlights, as well as colors
nine: re subclassing, localization are already subclasses through mixins to a large extent? 13:11
nine But does it have to be baked into the original implementation in a language as powerful as Raku? 13:12
lizmat sadly, it's still NQP at that point
nine Still there's obscure stuff like if $op<colonpair> -> $cp { my $ast := $cp.ast; $ast.set-key($op.adverb-pc2str($ast.key)); } which I guess is about translations 13:13
lizmat # Convert the given postcircumfix adverb if there is an original name
# for it. Otherwise it should just return the adverb unchanged.
nine Again, I can only guess that "original name" means that it's about translation 13:14
lizmat so is the issue with the naming of these methods ? 13:15
nine Not just. It's about the added mental load
Like having to look up <.meta-S> just to find out it's just 'S 13:16
lizmat well, that example is from EXPR-reduce, which already takes quite a mental load by itself
nine Exactly! It's not like it really needs any more complication to make it interesting.
Trying to make 3 zin 4 :x(5) call infix:<zin>(3, 4, :x(5)) is hard enough without the added distraction 13:18
lizmat so you'd rather we subclass EXPR-reduce for each localisation ?
I see no other way than that to get rid of the $op.adverb-pc2str(...) 13:20
finanalyst lizmat / nine: good afternoon
nine Or maybe leave EXPR-reduce alone altoghether and instead translate colonpairs in the generated AST as a parse-effect 13:21
finanalyst: good afternoon!
finanalyst sorry about making highlighting a problem
lizmat finanalyst: it's not just about highlighting, but localization in general 13:22
finanalyst OK.
interesting thing though is that highlighting needs to be fault tolerant in some way 13:23
lizmat nine: but in EXPR-reduce, the $op.adverb-pc2str() is the only localization specific thing in there ?
or am I missing something ?
nine may well be 13:24
lizmat nine: looks like "my $a; Int.?$a" codegens to a ::Call::BlockMethod, shouldn't that need to be a ::Call::VarMethod ? 13:31
same for Int.?&a and Int.?&a::b 13:33
nine Yes I think so
Surprising thing is that it works anyway 13:34
But I guess Var::Lexical's IMPL-EXPR-QAST gives the same result as IMPL-LOOKUP-QAST and in both cases we go through dispatch:<var> 13:35
Good news is that I did manage to make that infix adverb thing work :) Though I guess I'll rewrite my solution. Noticed that a slightly different variant already exists for prefix and postfix 13:45
lizmat real lunch& 13:48
14:34 finanalyst left 14:35 finanalyst joined 15:00 finanalyst left 15:47 finanalyst joined 15:55 eof left 15:56 summerisle joined 15:59 rba_ joined 16:00 rba left, rba_ is now known as rba 16:29 finanalyst left 17:19 sena_kun joined 17:53 finanalyst joined 21:48 sena_kun left 23:58 finanalyst left

Powered by Cro and the Raku® Programming Language.

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

Thank you!