🦋 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:01 reportable6 joined 01:16 Xliff left 01:37 NemokoschKiwi joined 01:39 NemokoschKiwi left 01:44 AlexDaniel joined 03:27 AlexDaniel left 03:50 epony left 04:51 epony joined 05:51 evalable6 left, linkable6 left 05:52 linkable6 joined 05:54 evalable6 joined 06:00 reportable6 left 06:01 reportable6 joined 07:01 benchable6 left, sourceable6 left, nativecallable6 left, quotable6 left, unicodable6 left, bloatable6 left, reportable6 left, greppable6 left, coverable6 left, tellable6 left, shareable6 left, notable6 left, bisectable6 left, releasable6 left, evalable6 left, committable6 left, notable6 joined 07:02 shareable6 joined, evalable6 joined, committable6 joined, coverable6 joined, unicodable6 joined, nativecallable6 joined, bisectable6 joined 07:03 reportable6 joined, tellable6 joined, benchable6 joined, bloatable6 joined, greppable6 joined 07:04 quotable6 joined, releasable6 joined, sourceable6 joined
Geth rakudo/main: 48e61f8a18 | (Stefan Seifert)++ | 3 files
RakuAST Fix stub packages preventing declaration of the real package

This is not yet 100 % there as we still run the BEGIN handler on the stub package. It's hard not to, because that's run before we even parse the package body, so we cannot know yet that it's just a stub.
rakudo/main: b4fe21c260 | (Stefan Seifert)++ | src/Raku/ast/pair.rakumod
RakuAST: fix canonicalization for non-literal colonpair values

If a name part doesn't have a simple compile time value, all we can do is deparse for canonicalization. Needed for e.g. Int:D(Cool)
08:23 Geth left, Geth joined
nine m: use MONKEY-SEE-NO-EVAL; EVAL Q[my Int:D(Cool) $i = "1"].AST 08:24
camelia Use of Nil in string context
in block <unit> at <tmp> line 1
Use of Nil in string context
in any IMPL-QUOTE-VALUE at src/Raku/ast/pair.rakumod line 55
Type check failed in assignment to $i; expected Int:D but got Str ("1")
in block <un…
nine Finally found a test that breaks because derived types don't stack yet
lizmat but: isn't my Int:D(Cool) wrong? Shouldn't it be Int(Cool) ? 09:31
I mean, we can only coerce instantiated values, no?
09:34 ab5tract joined
ab5tract nine: Is it possible to convert a `RakuAST::Declaration::External::Constant` into an actualy type object? I ask because the refinee of a SubsetHOW is a type object. I don't see any mention of the refinee in either base or ast QAST. 09:39
nine lizmat: that's from a spectest 09:47
ab5tract: .compile-time-value 09:48
Yeah, you will only find such details in the meta object itself, not in the QAST
09:49 sena_kun joined
ab5tract nine: thanks! 09:50
nine In general: from within the node (e.g. I need the code object this RakuAST::Routine represents) it's .meta-object and from outside it's .compile-time-value 09:53
ab5tract Very helpful, thanks! 10:05
Well, I've got it doing just about everything! ... except actually working
nine err...wat? 10:06
err...wat? 10:26
~. 10:29
ab5tract :) 11:04
I mean, it compiles, the QAST looks mostly good. It works when the subset is declared in packages. It just always fails the type check 11:05
nine Does it run the where expression? 11:07
ab5tract From what I can see, no. 11:09
no, it does not (according to my uber-sophisticated debug logging of inserting a 'say' into the where block) 11:11
lol 11:20
it was a matter of passing the `$!where` to the SubsetHOW.new_type generator before `$!where` was defined. Moved the assignment from PRODUCE-STUBBED-META-OBJECT to PRODUCE-META-OBJECT via a new method `set_where` on SubsetHOW and voila! 11:23
There's some copy-pasta in there that might appreciate some guru-level inspection, but otherwise this is looking good 11:24
lizmat ab5tract: please don't forget to add deparsing and tests :-)
or tell me to do it :-)
ab5tract yeah, that might be a bit tricky... so I take it tests are separate from the current test suite? 11:31
nine It's just tests in t/12-rakuast i.e. tests that create RakuAST nodes manually and check if they do the same as the parsed AST. 11:32
ab5tract Okay, interesting. 11:34
and deparsing?
damn, there's something broken about using WhateverCode with where 11:37
and setting a parameter to a subset type doesn't seem to do the check either 11:38
nine That's basically included in those tests. 11:39
I'd try it first with an explicit block. Then when that works move on to thunking 11:40
ab5tract yeah, using an explicit block doesn't do anything WRT parameter type checking 11:47
I do see in the source "# Do type checks.\n # TODO really more involved than this"
for `RakuAST::Parameter` 11:48
11:51 raschip joined
nine It already is much more involved than when that was written :) But anyway, what about my subset Foo where { $_ > 5 }; my Foo $i = 10; 11:53
ab5tract yeah, that works fine 11:57
as does `my subset Foo where 5; my Foo = 4` 11:58
nine Including running the where block?
ab5tract yes, the where block runs, according to any `say` implanted there 11:59
12:00 reportable6 left 12:01 reportable6 joined
ab5tract branch is now fully up to date 12:04
lizmat ab5tract: if you feel up to writing tests, please do 12:05
if you'd rather attack another piece of RakuAST, lemme take care of the tests and deparsing then, for efficiency's sake :-) 12:06
nine Well first that thing has to work anyway :) 12:07
ab5tract okay, sound good.
yeah, there's that lol
it also fails with confused when running: `'my subset Foo where { $_ > 5 }; my Foo $i where { $_ < 15 } = 10; say $i' 12:08
TIL you could double constrain like this
12:09 kjp left 12:10 kjp joined
nine The add-trait loop should be in actions. It's like that for all other trait holders 12:20
Geth rakudo/main: f98f316c19 | (Elizabeth Mattijsen)++ | src/Raku/ast/statements.rakumod
RakuAST: Add support for "use MONKEY"

The other MONKEY-... were already supported
nine Determining the current-package must be done in attach, not PERFORM-BEGIN. You don't know where we actually are when BEGIN is triggered. In attach you're guaranteed to get the right answer. 12:23
ab5tract ok, will make that change 12:24
Geth rakudo/main: 886a00d1cc | (Elizabeth Mattijsen)++ | 6 files
RakuAST: Add Nqp and Nqp::const classes

  - create new source and test file
  - move nqp logic from Call::Name to Nqp
  - add direct support for nqp::const in grammar
  - add deparsing
  - add tests
ab5tract it looks like the ast fails for `my $i where { $_ < 10 } = 5`, so it's not specific to subsets 12:25
s/the ast/RakuAST/
nine What does RakuAST::VarDeclaration::Implicit::Constant have to do with the traits in Subset? 12:26
ab5tract Nothing, that was just a thinko 12:27
You're referring to the comment about it maybe not being necessary?
nine yes 12:28
ab5tract Yeah, that's just a brain fart. Please ignore 12:31
Moving all current-package related stuff to `attach` results in "Lexical 'Foo' already declared" for 'my subset Foo of Int where { $_ > 5 }; my Foo $i = "6"; say $i.raku' 12:45
nine Err..."all current-package related stuff" what does that mean exactly? I said "determining the current-package". That's precisely what I meant ;) 12:48
ab5tract (^_^) 12:51
nine Does your PRODUCE_META actually get called when you try it on a parameter? 12:53
ab5tract checking 13:05
yes, it does 13:08
13:10 evalable6 left 13:13 evalable6 joined
ab5tract okay, this is interesting... 'module M { module N { subset F where { say "in where!"; $_ == 5 } } }; -> M::N::F $w { say $w }("w")' --> prints 'w' 13:14
adding 'of Int' a la 'module M { module N { subset F of Int where { say "in where!"; $_ == 5 } } }; -> M::N::F $w { say $w }("w")' --> dies with exception in binding parameter 13:15
but the exception mentions `Int`, not `M::N::F` as in base 13:17
nine Yes, that exception is due to failure to match the nominal type 13:18
The old frontend does generate QAST for doing that subset match: 13:19
│ │ │ - QAST::ParamTypeCheck
│ │ │ - QAST::Op(istrue)
│ │ │ - QAST::Op(callmethod ACCEPTS)
│ │ │ - QAST::WVal(Foo)
│ │ │ - QAST::Var(local __lowered_param__2)
ab5tract so, it's interacting with the subset to some degree, to get that nominal type? just not enough to actually run the where block.. 13:20
also: how does one generate a QAST::Var of "local __lowered_param_2" from code? 13:22
nine I think src/Perl/Actions.nqp:5956 is responsible for that. It adds the type as post constraint if its nominalizable 13:24
Oh, don't worry about that. That's the result of $get-decont-var() which you can just use as is. See related code in RakuAST::Parameter::IMPL-TO-QAST 13:26
ab5tract ok, nice! 13:27
Nemokosch ab5tract++ 13:28
ab5tract does `nqp::istype()` include all of the `is` classes in its lookup? I noticed this returned false for a `RakuAST::Trait::Of` when checking against `RakuAST::Trait` 13:38
erm, sorry. that might be a bit confusing: `nqp::istype($object, RakuAST::Trait)` returned false when $object was a `RakuAST::Trait::Of` 13:39
I'm wondering if something similar is happening when a `CurryThunk` is used as a where clause when it checks whether the type is `RakuAST::Code` 13:41
nine Hm....may be a good time to point a serious gotcha when working in NQP: it doesn't care if a multi part name actually exists. So it will happily accept I::Dont::Exist and just evaluate it to NQPMu
ab5tract that's very good to know 13:42
not sure if it applies here though? I tried using `set-traits($traits)`. That code checks whether every element in the list is of type `RakuAST::Trait` but failed when a `RakuAST::Trait::Of` element was found. 13:45
Rather than hacking that, I just unwrap the list and add the trait manually
but yeah, if `nqp::istype($thing, RakuAST::Code)` fails for a `RakuAST::CurryThunk`, it might explain what's going on with wheres and whatever codes at the moment. 13:47
Sorry, I'm jumping around between problems and questions that have come up while hacking on this 13:48
nine So it could be that OAOB
ab5tract hmm, my font is missing some crucial characters for rendering that line
nine Oops...sorry, very spotty connection on this train
It could be that you need some forward declarations for these types. 13:49
type.rakumod comes before code.rakumod in tools/templates/raku_ast_sources 13:50
ab5tract will plain old stubbing do? or do I need to do some fancy nqp magic 13:52
strangely enough, it does DWIM when I pass it an honest `RakuAST::Code` 13:56
a la `subset F where { $_ == 5 }` 13:57
FWIW, '-> Str $w where *.comb == 1 { say $w }("w")'' fails with the new frontend: 'This type cannot unbox to a native integer: P6opaque, WhateverCode' 13:59
okay, well I'm pretty stoked to have gotten subsets semi-working :D 14:00
current issues:
1) WhateverCode doesn't work
2) It doesn't work with parameters
nine Ok, disrecard the subbing thing. The RakuAST compiler does that already 14:12
And other classes like BeginTime refer to RakuAST::Code without doing anything special
ab5tract ah! `* ~~ 5` is not a RakuAST::Code, its a RakuAST::ApplyInfix 14:17
Nemokosch very fortunate; it would make typegenning for s/// and m// smartmatches to something other than ACCEPTS 14:19
ab5tract Nemokosch: I don't totally understand what you mean 14:20
tellable6 ab5tract, I'll pass your message to Nemokosch
Nemokosch sorry, this was somewhat off-topic 14:23
simply put, I'm very unhappy with the way 'foo' ~~ m/o/ and the likes work. Not the outcome per se but the technical implications of it 14:24
and the way RakuAST is designed could help saving the end-user behavior without the bizarre implications 14:25
nine Pro tip: when connected to the Wifi on a German train, set wireguard MTU to something smaller! 14:27
ab5tract: * ~~ 5 needs to be thunked 14:28
"thunking" basically means wrapping it in a block, so it becomes a code object 14:29
But then I see you already have code that should do that
Btw. your visit-children is incomplete. It's missing 2 children. All RakuAST nodes stored in your node must be visited 14:36
ab5tract good to know! 14:44
nine: something is broken with the current thunking WRT to WhateverCodes. The place I lifted my "thunking" from (signature's handling of where) is also broken for whatevercodes 14:45
shouldn't I be able to simply call $!expr.IMPL-CURRY ? 14:46
nine I am less than surprised :D 14:47
Currying should be done automatically by BEGIN handlers.
It's quite possible that we don't curry everything yet. Only infixes and postcircumfixes AFAIK 14:50
ab5tract infixes should cover Applyinfix, or is it just regular infixes at the moment? 15:11
nvm, I can look into the source :) 15:12
I can't see why this little thunk-wrapper isn't working as expected :/ 15:30
nine Of course it's always possible that the expectation is wrong 15:31
ab5tract how do you mean? 15:33
nine Maybe nothing. What t^Hdoes the QAST look like? 15:38
I see a big difference between the result of * == 5 and * ~~ 5 15:41
ab5tract indeed. There's a WVal(Regex) in the smartmatch 15:47
And both base and * == 5 include a 'QAST::Op(chain &infix:<~~>)' 15:48
(* == 5 includes 'QAST::Op(chain &infix:<==>) ', of course 15:49
15:50 AlexDaniel joined
nine Subset must not handle ApplyInfix any differently. If it needs to we have problems elsewhere 16:10
16:23 melezhik joined 16:30 melezhik left
ab5tract nine++ 16:31
16:33 melezhik joined 16:36 melezhik left
AlexDaniel m: say 42 17:15
camelia 42
AlexDaniel e: say 42
c: HEAD say 42 17:16
committable6 AlexDaniel, ¦HEAD(d52342e): «42␤»
evalable6 42
AlexDaniel uhhhhhh what's going on
that's 2 months old?? 17:17
shareable6: HEAD
shareable6 AlexDaniel, whateverable.6lang.org/HEAD
AlexDaniel c: 886a00d1cca211051421b466cb11fb2b14604663 say 42 17:19
committable6 AlexDaniel, ¦886a00d: «42␤»
AlexDaniel hm I don't get it 17:20
oh. You changed the main branch
lizmat yeah, shortly after 2022.12 17:21
it's got RakuAST in it now
AlexDaniel and it works and it's the default?
please fix anything here if it needs fixing: github.com/Raku/whateverable/search?q=master 17:22
I'll try to unstuck the repository
lizmat you need to activate it with "use experimental :rakuast" 17:25
AlexDaniel a ok then
lizmat and the new Raku grammar only passes about 50% of spectests
AlexDaniel c: HEAD say 42
committable6 AlexDaniel, ¦HEAD(886a00d): «42␤»
AlexDaniel m: say 42
camelia 42
lizmat that looks ok now :-)
AlexDaniel ok that was easier than I thought. Just removed the repos and let whateverable to clone them again
and it didn't need to build all the commits since 2022.12 because it keeps building commits on all branches anyway, even if it's not the main branch 17:26
[Coke] AlexDaniel++ 17:28
ab5tract nine: Could the issue be that typename in Actions isn't attaching a RakuAST::Type::Subset? 17:41
unlike all the other type options, there is nothing from syntactically that we can use to distinguish whether the parameter type is a subset 17:43
eg, it checks for colonpairs and then creates types that care about definedness, coercive when there is $<accept>, etc 17:44
nine But you already verified that Subset's PERFORM-BEGIN gets called even for a parameter, didn't you? 17:46
Ah, wait, that made no sense. Declaration vs. use 17:47
ab5tract right, was just realizing that
nine When the name is resolved, you know that you got a Subset type
ab5tract the where block definitely doesn't get called for parameter
Do you mean nominal types won't resolve? Or am I misunderstanding you 17:48
ie, are you proposing a way to know whether to create a Subset vs creating a Simple? 17:49
nine subset Foo where * == 5; sub foo(Foo $i) { } 17:54
When we parse the definition of foo, we encounter parameter $i and its type. We then resolve the name "Foo" and get a RakuAST::Term::Name that is resolved to the RakuAST::Type::Subset 17:56
I.e. in RakuAST::Parameter $!type.resolution gives you that Subset node. And $!type.meta-object gives you a SubsetHOW object 17:57
In RakuAST::Parameter::IMPL-TO-QAST we already check whether a type is archetype definite or archetype generic. Maybe we need to be even smarter there 18:00
18:00 reportable6 left, evalable6 left 18:01 evalable6 joined 18:03 reportable6 joined 18:15 AlexDaniel left 18:16 AlexDaniel left
nine ab5tract: in the old frontend I see something about nominalizable types getting pushed as post constraint on parameters 18:16
src/Perl6/Actions.nqp:5956 18:17
And in :10073 we generate an ACCEPTS call for each post constraint that isn't just a literal 18:18
While in the current RakuAST implementation only $!where gets that treatment 18:19
Geth rakudo/main: 97ecc4d713 | (Elizabeth Mattijsen)++ | 5 files
RakuAST: further refine handling of nqp::ops

  - Classes should inherit from RakuAST::Expression
  - Allow passing of List or RakuAST::ArgList as only argument
  - Convert Str|Int args on the fly to Str|IntLiteral
  - Remove unneeded methods now that we inherit from RakuAST::Expression
  - Add more tests
lizmat brings us to 128/140 for make test
nine Oooh...which one did it fix? 18:46
By now there are so few failing ones that I know them by name :)
lizmat not sure, actually... do you want me to figure out?
nine Only if you're curious, too
lizmat not really :-)
not enough 18:47
Nemokosch I am 🙊 18:49
lizmat then go back one commit, run the tests and remember the files that passed and see what the difference is
Nemokosch Okay, also not enough, to be honest xd 18:50
ab5tract nine: trying that now 18:52
lizmat nine: considering creating classes for pragmas, isms and repository (aka "use lib") 19:10
and plugging those in at the right place, eventually in the grammar
Geth rakudo: usev6++ created pull request #5179:
Fix test description for unknown modifier
rakudo/main: 69f1aa1f4f | (Christian Bartolomäus)++ (committed using GitHub Web editor) | t/02-rakudo/14-revisions.t
Fix test description for unknown modifier (#5179)

It looks like the test description has been copied from the previous sub-test in commit 3f25ba9212 (which added these tests).
rakudo/main: c88f50d5e8 | (Christian Bartolomäus)++ | 2 files
[JVM] Fix breakage with "use v6.e.PREVIEW"

After a recent rework of language versioning (merge commit a815b5ca12) the JVM backend started to throw an error when it encountered
   use v6.e.PREVIEW;
... (8 more lines)
rakudo/complex-sign: 8bd5eef1db | (Will Coleda)++ | 2 files
Add Complex.sign to v6.e
rakudo: coke++ created pull request #5181:
Add Complex.sign to v6.e
rakudo/main: 37f5259958 | (Elizabeth Mattijsen)++ | 2 files
RakuAST: add deparsing for Statement::No

And some tests
Nemokosch it's great to see [Coke] around with code as well 🙂 19:52
21:00 raschip left 21:27 NemokoschKiwi joined
ab5tract nine: I've got parameters working with subset types. But it throws a different exception than what we would expect: 'Internal error: inconsistent bind result' 21:27
WhateverCodes still not loving it 21:52
21:59 ab5tract left 22:11 sena_kun left 22:32 NemokoschKiwi left 23:00 ab5tract joined 23:09 shmup joined
nine lizmat: not sure it's worth it. But then I said the same about Stubs and you proved me wrong :) 23:11
ab5tract: inconsistent bind result appears when meta data (i.e. the Signature object) suggests a bind will be successful, but when we do the call, the parameter check fails 23:12
Nemokosch fyi I'm working on a fix for the map store breakage; for now it will probably be a quick-and-dirty solution, like moving the method declaration to Map might be enough 23:15
it would be good have systematic test cases for all possible storage scenarios which, if I can count, matches the nick of our beloved RakuAST expert 23:16
.oO(how many cases are a jnthn full?)
Nemokosch 🤣 23:18
tbh it could be organized into not more than three individual tests probably 23:20
nine ab5tract: so if I understood you correctly, it accepts an acceptable argument and refuses an unacceptable one but when refusing does so with an inconsistent bind result. Then the Parameter meta-object needs adjusting so it's clear the bind will not be successful.
Nemokosch storing a list with a Map, a Hash and a Hash::Object into a) a Map b) a Hash c) a Hash::Object
ab5tract nine: You've got it right. I was just coming to the realization and (hopefully a fix) right now 23:26
\o/ 23:29
Nemokosch [0] > my %map is Map = :foo Map.new((foo => True)) [1] > my %hash = :bar {bar => True} [2] > my %hash-object{Any} = :baz {baz => True} [3] > (%map, %hash, %hash-object).hash {bar => True, baz => True, foo => True} 23:39
hm, seems about right
ab5tract one more subtest is successful 23:45
23:56 epony left