Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
Nicholas good *, * 06:28
nine drakonis: it's still very much worth learning 06:36
drakonis certainly 06:38
nine Reading through the index I don't see anything that would be outdated by RakuAST. Maybe some details, but nothing major 06:41
jnthnwrthngtn RakuAST compilation still ultimately produces QAST, so even that part is still applicable :) 12:25
MasterDuke ah right, kind of forgot about that. planned to stay that way indefinitely? 13:29
jnthnwrthngtn MasterDuke: Well, certainly the distance from RakuAST to bytecode is fairly large. 16:22
And there's enough one would not want to have to do for every backend repeatedly 16:23
So something needs to go in that gap
lizmat Q: is an nqp::clone on an nqp::hash threadsafe ? 17:15
aka atomic?
jnthnwrthngtn lizmat: It'd need to iterate the source hash that it is copying (or at least work through its memory), and that's not atomic, so if something else writes the hash that is being cloned, it could be an issue. 19:51
It's no problem if other things are only reading the hash
So the typical pattern of "never mutate the hash, always clone it and mutate the clone and publish it" works
drakonis the move to rakuast would be able to allow the definition of both metaoperators and hyperoperators, yeah? 20:48
and is a recursive trait for subroutines a good idea? 20:55
specifically for stack optimizations related to that?
jnthnwrthngtn Syntax additions such as meta-operators will require slangs, which RakuAST is a prerequisite for, so it helps significantly in that direction, at least. 22:09
It'd be good to have some way to request a tailcall that either promises the current callframe will be re-used for the call or fails to compile if that for whatever reason can't be provided. 22:11
Not sure if a trait is really the right thing for that, more some special call form 22:14
It's less trivial than it looks, though, since if one looks at things like `sub foo($a) { with $a { foo(bar($a)) } }` the compilation of `with` implies a stack frame that binds the tested thing into `$_` at present, so "just replace the current frame" won't get you O(1) space. 22:16
And since there's currently no promise of tailcalls anywhere in the language, we freely produce closures for whatever block we might wish to in the compiler (of course, it's nice not to have the cost, so where possible they get optimized out). 22:17
So it's a question of how to provide a way to do this that isn't a stack growth foot gun. 22:19

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!