🦋 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.
02:09 [Coke] left, [Coke] joined 03:35 vrurg_ joined 03:36 vrurg left 05:25 MasterDuke left 05:40 sena_kun joined 07:51 kawaii joined
Geth rakudo/rakuast-phase-cleanup: 29c35a1b5e | (Stefan Seifert)++ | 3 files
RakuAST: make attribute initializers compile in correct context

Attribute initializers are transparently wrapped in a method that will be called by the object's constructor. Previously this method's AST node was created after we parsed the initializer. However since the method provides `self` as an implicit term if the initializer tried to use
  `self`, it would fail to resolve the symbol.
Fix by splitting off creation of the Method AST node and doing this at the variable declaration's parse time, so we can enter the method's scope before parsing the initializer.		 08:04
rakudo/rakuast-phase-cleanup: 34203afe7b | (Stefan Seifert)++ | 3 files
RakuAST: make attribute initializers compile in correct context

Attribute initializers are transparently wrapped in a method that will be called by the object's constructor. Previously this method's AST node was created after we parsed the initializer. However since the method provides `self` as an implicit term if the initializer tried to use
  `self`, it would fail to resolve the symbol.
Fix by splitting off creation of the Method AST node and doing this at the variable declaration's parse time, so we can enter the method's scope before parsing the initializer.		 09:15
nine Turns out, there was a neat solution after all :) We already stub declared variables and this happens right before parsing the initializer. So this gave me a place where I can create that wrapper method at parse time and then parse the initializer in this method's scope. If there's no initializer, we just discard the method again (that got added in the second push) 09:17
6 more spectest files to pass before I can merge rakuast-phase-cleanup 09:18
lizmat nine++ 09:21
10:00 kawaii left
Geth rakudo/rakuast-phase-cleanup: 24 commits pushed by (Stefan Seifert)++
review: github.com/rakudo/rakudo/compare/3...132aa79827		 10:15
11:34 librasteve_ joined
librasteve_ o/ 11:34
Geth rakudo/rakuast-phase-cleanup: c19a9c1598 | (Stefan Seifert)++ | src/Raku/ast/expressions.rakumod
RakuAST: have double parentheses act as currying barrier
 12:13
nine 5 more spectest files before rakuast-phase-cleanup is complete 12:15
Huh.... why does this give a single curried expression: 12:24
m: dd (* > 1) + 3
camelia WhateverCode.new
nine while this gives 3: 12:25
m: dd (* > 1) xx 3'
camelia ===SORRY!=== Error while compiling <tmp>
Two terms in a row
at <tmp>:1
------> dd (* > 1) xx 3⏏'
expecting any of:
infix
infix stopper
postfix
statement end
statement modifie…
nine m: dd (* > 1) xx 3
camelia (WhateverCode.new, WhateverCode.new, WhateverCode.new).Seq
lizmat xx's left side is thunked ? 12:40
nine m: dd * > 1 xx 3 12:49
camelia WhateverCode.new
nine Not always it seems 12:50
lizmat well, they produce different ASTs 12:58
Geth rakudo/rakuast-phase-cleanup: 0253b05c26 | (Stefan Seifert)++ | src/Raku/ast/expressions.rakumod
RakuAST: honor xx's currying barrier
 13:41
15:23 librasteve_ left
Geth rakudo/rakuast-phase-cleanup: 6fce6f65d0 | (Stefan Seifert)++ | src/Raku/Actions.nqp
RakuAST: need to call IMPL-BEGIN on synthetic node trees

to-begin-time only handles the node it's called on. To get fully recursive running of BEGIN handling, one needs to call IMPL-BEGIN		 15:40
rakudo/rakuast-phase-cleanup: 38 commits pushed by (Jonathan Worthington)++, (Stefan Seifert)++
review: github.com/rakudo/rakudo/compare/6...d7a8e52bac		 15:57
nine :
And with this, rakuast-phase-cleanup passes all spectest files that main does plus two more :) 16:05
lizmat WOW! 16:08
nine There are still some RakuAST specific tests failing 16:12
lizmat such as? 16:17
nine t/12-rakuast/class.rakutest fails because we don't declare the %_ lexical in the test method 16:19
My guess is that we cache the AST declarations before we create those implicits 16:20
lizmat and that isn't caught by another test? 16:24
nine only happens with synthetic ASTs 16:25
lizmat but synthetic ASTs should probably define *%_ explicitely? 16:26
on methods, I mean
if not, then that's a deficiency in the test ? 16:27
*they do not
because for sure, I would like to be able to create methods that do *not* have an implicit *%_ 16:28
as a candidate in dispatch for when *no* named args are specified
nine So we're back to AST nodes for these implicits getting generated at BEGIN time while already at PARSE time we try to look up names which triggers caching of AST declarations.. 16:42
lizmat eh... couldn't we adjust the Actions to always *explicitely* add *%_ to methods ? 16:44
nine That's not the only implicit 16:45
lizmat you mean, self also ?
nine yes 16:46
lizmat is that the only one, or are you referring to $_ $/ $! as well? 16:48
nine invocant and slurpy hash are the ones created by IMPL-ENSURE-IMPLICITS 16:49
lizmat well, to me "self" feels like a very special case that we could possibly solve another way, really late? 16:50
and if %_ is the only other one, then I'd say we handle *that* in Actions
and thus get rid of IMPL-ENSURE-IMPLICITS ? 16:51
nine self still has to be added early enough to be done before we start resolving names
lizmat m: my method a { my \self = 42 } 16:52
camelia ===SORRY!===
Lexical 'self' already declared
lizmat I mean, do we really have to resolve "self"? couldn't we equate that to the first argument always ? 16:53
if the callable is a method ? 16:54
nine You still need to find that AST node representing the thing self points at, to have it generate the required QAST
lizmat but: RakuAST::Term::Self is already a whole class to itself 16:55
couldn't that be used as a hook to have it find where it points at? 16:56
nine m: my \self = "hi"; say self # A Term::Self does *not* always refer to the first argument of an enclosing method. 17:04
camelia ===SORRY!=== Error while compiling <tmp>
'self' used where no object is available
at <tmp>:1
------> my \self = "hi"; say ⏏self # A Term::Self does *not* always re
expecting any of:
argument list
term
nine Apparently that check is NYI in RakuAST. Anyway: 17:05
m: my method foo() { { my \self = "hi"; say self } }
camelia ( no output )
nine m: my method foo() { { my \self = "hi"; say self } }(1) 17:06
camelia hi
lizmat heh :-) 17:07
afk for a few hours&
nine I guess better no check than a broken one like we've just seen with the old frontend 17:08
method ast-lexical-declarations() # Find the lexical declarations due to AST nodes. This does not include any generated ones thanks to BEGIN-time effects (for example, those due to `import` or `use`). These are cached rather than walking the tree every time. 17:55
method generated-lexical-declarations() # Get a list of generated lexical declarations. These are symbols that are produced thanks to BEGIN-time side-effects.
These comments strongly suggest that these implicitly generated declarations should just be listed as generated declarations as they are indeed crated due to BEGIN-time effects. 17:56
The problem with this is that they are still connected to the tree. Thus ast-lexical-declarations will find them if they have already been added at the first time it runs on that scope.
18:33 [Tux] left 18:38 [Tux] joined 19:48 vrurg joined 19:51 vrurg_ left
Geth rakudo/rakuast-phase-cleanup: 1229c9faba | (Stefan Seifert)++ | 3 files
RakuAST: defuse timing around signature implicits

In synthetic ASTs, lookups are done at parse time while signature implicits are only created at begin time. Lookups trigger caching of AST declarations in scopes, so the implicits will get ignored later on. However declarations added at begin time are supposed to be added as generated declarations anyway. Only trouble was that these declarations would also get connected to the AST, thus they could be found twice when they were created before the AST declaration cache was filled. Simply deduplicate both lists when generating QAST to get out of this conundrum.		 20:01
nine Fixes 3 of the failing test files and gains us one more spectest file. 20:02
lizmat nine++ 20:14
21:07 sena_kun 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!