🦋 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
|