🦋 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 00:51 [Tux] left 01:29 [Tux] joined 01:36 frost joined 02:30 Xliff joined 03:02 squashable6 left 03:04 squashable6 joined 04:21 vrurg_ joined, vrurg left 05:11 [Coke] left 05:19 [Coke] joined 06:00 reportable6 left, reportable6 joined 06:53 Xliff_ joined 06:55 Xliff left 09:45 sena_kun joined
lizmat jjatria++ 09:45
Geth rakudo/main: 0040f81316 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | 3 files
Eradicate knowledge of COMPOSE phaser

There were some speculations, and an attempt at creating a stub that was supposedly create a NYI error, but didn't. Meanwhile, the mainline of a role is run every time it gets composed into a (new) class, so effectively we already *have* an implicit COMPOSE phaser. So there's no need for a COMPOSE phaser, it appears.		 09:51
10:09 ab5tract joined 10:27 sena_kun left 11:03 frost left 11:12 sena_kun joined 11:16 frost joined, ab5tract left 11:29 ab5tract joined
lizmat ab5tract looks like "my subset Foo of Int where * %% 2" isn't working correctly 11:32
this arrives as an ApplyInfix in $!where, which is then wrapped in a Block 11:33
which feels to me it is actually wrapping a WhateverCode in a Block ?
now, I'm still not grokking how a WhateverCode comes to be exactly, so there's that ;-) 11:36
11:42 ab5tract left
leont I can imagine them being very tricky, but also very useful to convert to RakuAST 11:48
lizmat RakuAST::ApplyInfix.new( 11:51
left => RakuAST::Term::Whatever.new,
infix => RakuAST::Infix.new('%%'),
right => RakuAST::IntLiteral.new(2)
)
the Whatever.new is enough to turn this ApplyInfix into a WhateverCode 11:52
which is great
now, I wish I grokked the mechanism behind it :-)
11:53 ab5tract joined
ab5tract lizmat: That should have been covered in my test suit 11:54
*suite
it should not be wrapped in a block because it should get caught by the IMPL-CURRIES guard
My test case was for * == 5, but it should also work the same for * % 5 11:55
* % 5
* % 5; # geez
why is my IRC client gobbling a % sign? 11:56
* % % 5
* % 5
bizarre
lizmat no idea :-)
.IMPL-CURRIED or .IMPL-CURRIES ? 11:57
ab5tract IMPL-CURRIED means that the expression has already been curried 11:58
so that one 11:59
lizmat hmmm... not .IMPL-CURRY ?
12:00 reportable6 left
ab5tract the PERFORM-BEGIN of ApplyInfix already does all the currying stuff 12:00
that's why subset does its PERFORM-BEGIN-AFTER-CHILDREN
12:01 reportable6 joined
ab5tract nine might be able to explain it a bit better 12:01
IMPL-CURRIED returns the curried version of the expression
so you can use it as a truthy condition as well as a location to get the important details, like when we set_where 12:02
lizmat aha!
I think I understand what's going on... the problem is really that visit-children is being called 5 times for different used 12:08
I think I understand what's going on... the problem is really that visit-children is being called 5 times for different uses
Geth roast: 00b1595a2a | ab5tract++ | S12-subset/type-subset.t
Add simplified subset tests

These were created during the development of RakuAST::Type::Subset.
They respresent a smaller footprint of tests required for bootstrapping subsets than the current subset test suite.		 12:09
ab5tract Now make spectest will provide the right feedback for your efforts lizmat :) 12:10
lizmat thanks!
ab5tract Getting ApplyInfix to work took me ages 12:11
it's a shame that we couldn't keep the original solution due to deparse, but I understand 12:12
12:13 frost left
lizmat 682 / 1356 :-( 12:21
but at least all of the additional RakuAST subset tests pass now
Nemokosch 😅 12:24
nine Why couldn't we eep the original solution?
Nemokosch so... what changed overall?
lizmat because the "where" would change depending on its contents 12:31
and thus not represent the originally given arguments 12:32
"where 42" becomes "where { 42.ACCEPTS($_) }" internally
ab5tract lizmat: Just a heads up that parameters have the same issue 12:34
lizmat and other places, yes 12:35
nine Yes, we do it like that everywhere 12:38
Geth rakudo/main: f89db51c7c | (Elizabeth Mattijsen)++ | src/Raku/ast/type.rakumod
RakuAST: Fix handling of non-blocky "where"s

Basically copy the original "where" at object creation to a private
  $!block attribute, and use that attribute further on, leaving the
original $!where untouched
rakudo/main: 7ad82e9c6a | (Elizabeth Mattijsen)++ | t/12-rakuast/subset.rakutest
RakuAST: add tests for where literal / regex
lizmat I guess we need more RakuAST:: tests then :-( 12:39
BTW, I was thinking maybe we could use a $?AST compile time variable that would contain the AST of the current $?BLOCK ? 12:40
nine And how will the optimizer now optimize those where blocks?
lizmat like any other block visited ?
visit-children does not list the $!where, but it does list the $!block 12:42
nine What if the where node gets modified after being added to the subset node?
lizmat what would modify that? 12:43
assuming we would allow a "set-where" on the Subset class 12:44
then that method would be able to do the right thing?
nine Whoever creates the AST
Or a macro 12:45
lizmat how would you modify it? with a bindattr ?
or creating a new AST with elements of the old? 12:46
nine Are AST nodes supposed to be immutable? 12:49
lizmat I'm not sure 12:51
not sure what jnthn's thinking is on that 12:52
nine On the flip side: does deparse _have_ to replicate the original source (if that even exists) even after BEGIN handlers are run? 12:54
lizmat I think it does
nine why? 12:55
lizmat because you want to be able to use the deparsing logic for tidying / linting
nine Linting is about the source. Why would that run BEGIN handlers? 12:56
lizmat Linting is about creating a representation of the source that can be easily inspected 12:57
I think ASTs are such a representation
or would you like to maintain another grammar to provide linting services ? 12:58
and keep them in sync with the core ?
nine Sure you turn the source into an AST. But why do you need to run BEGIN handlers after that? 13:01
lizmat well, I guess currently you don't have a choice ?
when you call the .AST method on a string ? 13:02
I mean, we could also envision the "where 42" to "where { 42.ACCEPTS($_) }" at the QAST level, I guess 13:03
but that would be much less convenient ? 13:04
nine The current .AST method is just a debugging aid though. I expect that to go away again when we're done. 13:07
13:13 linkable6 left, evalable6 left 13:14 linkable6 joined 13:15 evalable6 joined
lizmat perhaps: I can also see use of that for macro-builders fwiw 13:17
nine Somethng like that. But at that point we should have a discussion on what the interface really should look like and what we do promise and what we don't. 13:18
lizmat fwiw I see in class use of RakuAST classes as an easier way to build the final QAST, and as such a by-product 13:22
or half product, if you will :-)
as to the interface: using RakuAST:: classes is cumbersome, I know from writing many tests with it 13:23
and I have some ideas on making things easier
which may involve macros :-)
nine Sure. But Str.AST is ridiculously huffmanised. This is something that almost no one will ever use 13:24
lizmat so what would you call it then?
nine I don't know. We're not having that discussion yet :) First order of the day is finishing RakuAST 13:25
lizmat agree, but in such a form that we don't have to go over it again to make it really useful for macros, linting, tidying etc 13:29
ab5tract: t/spec/S12-subset/type-subset.t is not passing on base either?? 13:54
and the plan is off ? 13:57
ab5tract hmm, what's broken with base? 14:01
let me look into it. sorry for the error
it's only expressions that worked in base and not in branch, so I don't know how that could have happened 14:02
lizmat afk for a few hours& 14:05
Geth roast: 9779702e98 | ab5tract++ | S12-subset/type-subset.t
Fix poorly formed test and bad plan

  lizmat++ for point this out		 15:06
roast: 887d301936 | ab5tract++ | S12-subset/type-subset.t
Use a more targeted and sensible test case
 15:10
15:14 Xliff_ left
Geth roast: f53b0cda7c | ab5tract++ | S12-subset/type-subset.t
Fully convert test cast to sonsibility
 15:47
ab5tract jeez, you give a person a commit bit and all they do is push too fast :/ 15:48
I'lm used to working in branches, will slow my roll in the future when pushing
Geth roast: b7c8177bc9 | thundergnat++ (committed using GitHub Web editor) | S12-subset/type-subset.t
fix minor typo
 15:58
ab5tract nine: is there some way to get an expression "reduced" ? 16:08
ie, to have a Rat literal instead of an ApplyInfix [/]
the rules for enums are so fuzzy wuzzy
and I need to crawl the expression to get values, etc 16:10
it would also be much more comfortable dealing with Pairs directly instead of having to deal with colonpairs and applyinfix separately 16:12
(applyinfix =>)
Nemokosch the question is - is => a real operator from core? if it is, perhaps the principle of silently resolving it to a Pair in the parsing step is wrong 16:21
nine ab5tract: what do you need that for? 16:22
ab5tract IIUC it should always resolve lexically
nine: I'll push and create a draft so you can see what I mean
Geth rakudo: ab5tract++ created pull request #5207:
DRAFT: Add RakuAST::Type::Enum		 16:30
ab5tract It starts to get cumbersome around here: github.com/rakudo/rakudo/pull/5207...17ca34R409 16:32
lizmat ab5tract: I found if things get cumbersome, maybe it is time to add a helper method in core ?
Geth roast: 262e710b23 | (Elizabeth Mattijsen)++ | spectest.data
Make sure we actually run S12-subset/type-subset.t
 16:34
ab5tract you mean helper methods on other RakuAST classes? or elsewhere? 16:35
lizmat ab5tract ^^ :-) I was wondering why still stuck at 682
ab5tract lizmat++ :D
lizmat no, in base core. e.g. I added a Stash.VIVIFY-KEY method to handle OUR variable initializations
ab5tract I vow that my next roast contribution won't take 5 or 6 commits to get right
lizmat ++ab5tract 16:36
nine ab5tract: do I read that correctly that you are after the literal values? 16:40
Not AST nodes?
ab5tract Basically, yes. 16:41
nine Why don't you just interpret that AST then and use the result?
ab5tract I guess that's what I was asking how to do :) 16:42
nine IMPL-BEGIN-TIME-EVALUATE
ab5tract thanks!
okay, I'm not sure about this one.. another example of nqp::istype not working as expected for me: 17:32
in the same block: 'nqp::say($_.WHAT.raku)' outputs Pair but nqp::istype($_, Pair) fails to match 17:33
lizmat the first is a Raku HLL Pair object, the second an NQP Pair object ? 17:39
*type
ab5tract I didn't see that there was an NQP pair type. I searched through the ops.markdown for one
lizmat: so what's my best bet for hitting a guard then? '$_.WHAT.raku eq "Pair"' feels really horrible 17:40
lizmat % nqp -e 'nqp::say(~Pair)' 17:46
no error, so there is an NQP Pair object
ah, no
% nqp -e 'nqp::say(~Foo)'
meh
ab5tract I think you are right that there is one
It
It's just not possible/supported to create one directly 17:47
lizmat could well be... wish jnthn was back on #raku-dev
ab5tract Yeah... one day, maybe 17:48
other than the weirdness of checking whether it is a Pair or not, IMPL-BEGIN-TIME-EVALUATE has been a total dream to use 17:49
18:00 reportable6 left 18:01 reportable6 joined 18:02 sena_kun left
nine Is Pair even declared in the bootstrap? 18:03
lizmat nope 18:10
nine Then it isn't available directly in RakuAST. That's what IndirectLookup is for 18:12
18:16 ab5tract left 18:30 ab5tract joined
ab5tract how do I utilize indirect lookup here? I don't see other examples while searching RakuAST 18:31
just references to a way to produce QAST for indirect lookups
18:37 sena_kun joined 19:30 ab5tract left 19:53 ab5tract joined
ab5tract make 19:59
nine I meant ImplicitLookup 20:07
Nemokosch uh oh, that word is traumatic 😆 20:08
nine implicit lookups are resolved before BEGIN handlers are run, so you can use that just fine to get Pair from the setting 20:09
ab5tract Nemokosch: Did you ever get your thing figured out? 20:15
tellable6 ab5tract, I'll pass your message to Nemokosch
Nemokosch no, I've run out of copium 20:16
ab5tract fair enough 20:17
20:38 codesections joined
ab5tract damn, it looks like ImplicitLookups + InstallsPackage somehow causes ambiguous hierarchy 20:49
22:18 squashable6 left 22:20 squashable6 joined
Nemokosch what's InstallsPackage? 22:29
23:33 codesections 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!