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