🦋 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 01:25 epony left 02:03 raschip joined 03:27 raschip left 06:00 reportable6 left 06:03 reportable6 joined
releasable6 Next release in ≈2 days and ≈11 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 07:00
08:52 sena_kun joined
Geth nqp/main: 081af2885f | cfa++ (committed using GitHub Web editor) | README.pod
Update branch references in README.pod (#796)

Replace references to `master` with `main`.
  dev.azure.com links left unchanged for now, as apparently
  `main` isn't currently being built there.
09:01
10:31 sena_kun left
lizmat Sanity check: Missing serialize REPR function for REPR MVMContext (BOOTContext) 10:53
indicates a context being serialized when it shouldn't, right ? as you cannot serialize contexts? 10:54
nine yes
lizmat check 11:03
11:11 sena_kun joined
Geth rakudo/main: 03b3b13dbd | (Elizabeth Mattijsen)++ | 7 files
Fix type constraints on QuantHashes

It looks that by abstracting the constraint adding, some context is introduced that cannot be serialized. Fixed for now by copy-pasting the code and removing the abstraction.
Partial fix for #2544
11:52
12:00 reportable6 left 12:01 reportable6 joined 12:36 Xliff joined 12:45 lizmat_ joined, Geth left 12:47 RakuIRCLogger left 12:48 lizmat left 12:49 MasterDuke left 12:53 ab5tract joined 13:21 Xliff left 14:23 RakuIRCLogger__ left 14:24 Geth joined, lizmat_ left, lizmat joined 14:28 Geth left, Geth joined 14:37 vrurg left 14:38 vrurg joined
Geth Net-SMTP/main: 9cfea91ba9 | (Polgár Márton)++ | 4 files
1.2.2
14:41
rakudo: ab5tract++ created pull request #5178:
[DRAFT] Add RakuAST::Type::Subset
14:43
nine ab5tract: does nqp::say($<EXPR>.ast); actually work? For dumping ASTs I use .ast.dump and for names $name.canonicalize 14:56
ab5tract: on a first glance, it looks like you're on the right track! I'd use a RakuAST::Expression $!expr instead of $!code and store the expression directly 14:59
Geth rakudo/main: 015aacf2f9 | (Elizabeth Mattijsen)++ | 15 files
Change deparsing of Blockoid with <2 statements

Instead of going the full
  -> {
   42
  }
it will now just do "-> { 42 }"
Adjust deparsing tests accordingly.
15:07
lizmat nine: I'm considering a separate RakuAST::NQP class to facilitate writing nqp::ops to be codegenned directly, without needing RakuAST::Name 15:10
opions?
use case: generating the BUILDALL method for classes
nine lizmat: that would require the parser to know how that distinction 15:14
lizmat no, not to be used in the Grammar, just to build code with nqp ops 15:15
RakuAST::NQP.new("create", Type::Simple.new...) 15:16
nine That sounds even more confusiing :) Note that I'm not actually against teaching the parser that. Might even simplify code and speed up processing. 15:17
lizmat ok, so what do you have in mind ?
nine With confusing I was referring to having a RakuAST::NQP node but not generating it from the parser. Going all the way sounds fine 15:18
lizmat ah, ok, will look at that after getting some fresh air :-)
ah, ok, will look at that after getting some fresh air :-) 15:19
&
ab5tract nine: yeah, nqp::say($<EXPR>.ast) prints the object .WHICH info 15:27
thanks for mentioning .ast.dump! 15:30
I'm a bit confused why I can't resolve the name through the resolver, as all the other classes in `type.rakumod` seem to be able to do 15:39
Adding `$*R.declare-lexical()` to the action code doesn't work: there is an error about an element of type Type::Simple not being resolved 15:41
And `subset F where 5; F.WHAT.say` produces a "Can't look up attributes in a Any type object" unhandled exception 15:42
nine What name can it not resolve?
ab5tract It's a sorry stating "This element has not been resolved. Type: RakuAST::Type::Simple" 15:43
nine: oh, sorry. I try to resolve what's been assigned into the $!name variable 15:45
Which in my example is 'F'
nine Oh, there's no point in resolving that as it's the name that your node is currently declaring. So what would be the result of the lookup?
The obvious question is then of course: why do all the existing Type nodes look up names? Type::Simple is not a declaration. It's e.g. what's used in my Int $foo; or Int.new. There we need to find what "Int" means. 15:46
ab5tract Ah, fair point. So then I don't need to derive from `RakuAST::Lookup` 15:47
nine Then there are the derived types, e.g. ::Definedness, ::Concrete, etc, i.e. Int:D. "Int:D" has a base type "Int" and again, we need to know what that is.
ab5tract right
makes sense
nine You will need a lookup for subset Foo of Int, but I guess that will come later
Oh and that will probably be handled elsewhere anyway, since "of" is followed by a type, so you already get a (presumably) RakuAST::Type::Simple node for that 15:48
ab5tract nine: That seems to be handled by the `of`` trait? Or will be, I guess? The `of`` type doesn't show up in the match object 15:49
or I guess it does.. somewhere in $<trait>[0]
nine True, that's a trait.
ab5tract so that makes sense: I don't need to declare a resolves-with because I can leave out the `is RakuAST::Lookup`. I was already experiencing along those lines 15:51
15:51 ab5tract left 15:52 ab5tract joined
nine The most difficult part in this may actually be the stuff surrounding where, like thunking 15:53
But then there's prior art in other places where we already handle "where"
ab5tract Yeah, that's a very curious part indeed. I was going to run some method that would do what `make_where_clause` or whatever in the old edition does 15:54
Ohh, there's other places that do this?
I guess I'm still at a loss as to what I need to do to have `F.WHAT.say` print the type object `(F)` instead of exploding 15:55
I suspect it's something about the QAST objects
nine F.WHAT.say? 15:56
ab5tract right, there's no record of the type in scope once declared. `subset F where 5;` runs fine. `subset F where 5; F.WHAT.say` explodes 16:01
nine Compare the generated QAST between old and new frontend. 16:02
This is about the "Can't look up attributes in a Any type object", isn't it? Where exactly does that get thrown? --ll-exception is your friend 16:03
ab5tract nine++ 16:10
Thanks for the suggestions
Do I need to be manually sinking? One difference I see is that `QAST::Op(p6sink)` exists in rakuast whereas things seem to already be sunk in head 16:28
s/head/main/ or whatever we call it 16:29
nine No. Don't worry about that. If you want to check if sinking was done correctly, check the --target=ast output. There's an anchor symbol next to every node that's sunk 16:30
afk& 16:33
17:34 Xliff joined 18:00 reportable6 left 18:02 reportable6 joined 18:06 sena_kun left 18:53 sena_kun joined 18:55 NemokoschKiwi joined, NemokoschKiwi left
ab5tract nine: Alright, gotten a few steps closer. Now I'm at the step of trying to figure out how to actually have the assignment call the where code 19:27
19:57 raschip joined
nine ab5tract: look at the QAST generated by the old compiler frontend. It may even be that you don't actually have to generate code for that yourself 20:40
vrurg If memory serves me right, this is done by SubsetHOW. 20:42
ab5tract: Optimizations aside, do a normal ACCEPTS. Will work for now. 20:43
20:48 raschip left
nine QAST looks like nothing special is required 20:50
ab5tract Am I trying to match the QAST 1:1? 21:19
A major difference I see is that I cannot for the life of me get ` - QAST::Var(lexical F :decl(static))` to appear in the QAST:Stmnts list 21:21
in the RakuAST version
It's also (probably not surprisingly) not showing up if I run `'subset F where /5/; ::.keys>>.say'` 21:40
22:44 ab5tract left 22:51 NemokoschKiwi joined, NemokoschKiwi left, NemokoschKiwi joined 23:24 sena_kun left 23:25 NemokoschKiwi left
lizmat so why *are* List and Map Cool ? 23:49