[00:08] *** reportable6 left [00:09] *** reportable6 joined [01:04] *** frost joined [06:28] good *, * [06:36] drakonis: it's still very much worth learning [06:38] certainly [06:41] Reading through the index I don't see anything that would be outdated by RakuAST. Maybe some details, but nothing major [06:59] *** Voldenet left [07:03] *** Voldenet joined [09:48] *** linkable6 left [09:48] *** evalable6 left [09:49] *** evalable6 joined [09:50] *** linkable6 joined [11:24] *** discord-raku-bot left [11:24] *** discord-raku-bot joined [11:49] *** Altai-man left [12:16] *** dogbert11 joined [12:17] *** dogbert17 left [12:25] RakuAST compilation still ultimately produces QAST, so even that part is still applicable :) [12:30] *** dogbert17 joined [12:32] *** dogbert11 left [12:44] *** sena_kun joined [12:58] *** dogbert17 left [12:58] *** dogbert11 joined [13:09] *** TempIRCLogger joined [13:29] ah right, kind of forgot about that. planned to stay that way indefinitely? [13:47] *** dogbert11 left [13:47] *** dogbert17 joined [14:18] *** dogbert17 left [14:21] *** dogbert17 joined [14:44] *** frost left [15:16] *** [Coke]_ joined [15:17] *** sena_kun left [15:18] *** [Coke] left [15:18] *** sena_kun joined [15:40] *** [Coke]_ is now known as [Coke] [16:22] MasterDuke: Well, certainly the distance from RakuAST to bytecode is fairly large. [16:23] 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 [17:15] Q: is an nqp::clone on an nqp::hash threadsafe ? [17:15] aka atomic? [18:43] *** rypervenche left [19:47] *** nebuchadnezzar left [19:48] *** nebuchadnezzar joined [19:51] 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 [19:51] So the typical pattern of "never mutate the hash, always clone it and mutate the clone and publish it" works [20:46] *** rypervenche joined [20:48] the move to rakuast would be able to allow the definition of both metaoperators and hyperoperators, yeah? [20:55] and is a recursive trait for subroutines a good idea? [20:55] specifically for stack optimizations related to that? [22:09] 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:11] 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:14] Not sure if a trait is really the right thing for that, more some special call form [22:16] 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:17] 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:19] So it's a question of how to provide a way to do this that isn't a stack growth foot gun. [22:31] *** linkable6 left [22:31] *** evalable6 left [22:32] *** linkable6 joined [22:33] *** evalable6 joined [23:33] *** evalable6 left [23:33] *** linkable6 left [23:33] *** evalable6 joined [23:35] *** linkable6 joined