[00:04] *** daxim left [00:04] *** daxim joined [00:10] *** melezhik left [00:11] *** rbt left [00:11] *** rbt joined [00:31] *** Xliff left [00:38] *** softmoth left [00:56] *** pilne_ left [00:58] *** pilne joined [01:10] jmerelo: if I keep noticing that I'm still browsing docs.PERL6.org and there's no redirect or even indication that I'm on the wrong domain I'm gonna start a riot. [01:11] AlexDaniel, I'll pass your message to jmerelo [01:11] *** Tirifto left [01:11] rba: by any chance can we start redirecting? Can you remind me why didn't we start doing it right away? [01:15] *** sena_kun joined [01:17] *** Altai-man_ left [01:19] *** melezhik joined [01:19] *** melezhik left [01:30] *** molaf left [01:40] *** Doc_Holliwood left [01:43] *** molaf joined [01:52] *** softmoth joined [01:54] *** Redfoxmoon left [01:54] *** Redfoxmoon joined [02:02] *** softmoth left [02:03] *** softmoth joined [02:05] *** Manifest0 left [02:06] *** Manifest0 joined [02:08] *** farcas1982regreg joined [02:10] *** softmoth left [02:11] *** softmoth joined [02:22] *** xinming_ left [02:23] *** xinming_ joined [02:33] *** k-man_ is now known as k-man [02:38] *** xinming_ left [02:38] *** kst` left [02:38] *** xinming_ joined [02:42] releasable6, status [02:42] Kaiepi, Next release will happen when it's ready. 5 blockers. 166 out of 336 commits logged (⚠ 3 warnings) [02:42] Kaiepi, Details: https://gist.github.com/7956ece1e254fbdd11dd028ebc38b59b [03:14] *** Altai-man_ joined [03:17] *** sena_kun left [03:34] ¦ whateverable: b7e2a61920 | (Aleks-Daniel Jakimenko-Aleksejev)++ | META6.json [03:34] ¦ whateverable: Bump version [03:34] ¦ whateverable: review: https://github.com/Raku/whateverable/commit/b7e2a61920 [03:46] *** xinming_ left [03:47] *** xinming_ joined [04:16] *** Redfoxmoon left [04:16] *** Redfoxmoon joined [04:26] *** cpan-raku left [04:26] *** cpan-raku joined [04:26] *** cpan-raku left [04:26] *** cpan-raku joined [04:27] *** pilne left [04:37] *** Doc_Holliwood joined [04:50] *** aborazmeh joined [04:50] *** aborazmeh left [04:50] *** aborazmeh joined [05:08] *** xinming_ left [05:08] *** xinming_ joined [05:15] *** Sgeo left [05:15] *** sena_kun joined [05:15] *** Sgeo joined [05:17] *** Altai-man_ left [05:33] *** farcas1982regreg left [05:41] *** bdju left [05:43] *** bdju joined [06:13] *** kensanata joined [06:14] *** sjm_uk joined [06:23] *** rindolf joined [06:29] *** xinming_ left [06:29] *** xinming_ joined [06:32] Good morning everybody [06:33] if you want https://news.perlfoundation.org/post/gp_rakuast to get approved, a supportive comment on that blog post might help convince the grant committee [06:33] and conversely, if you think it's a bad idea, also let us know in the comments! [06:35] *** xinming_ left [06:36] *** Doc_Holliwood left [06:38] *** xinming_ joined [06:55] *** xinming_ left [06:57] *** xinming_ joined [07:00] *** epony left [07:00] *** sacomo left [07:01] *** sacomo joined [07:07] *** farcas1982regreg joined [07:07] *** wamba joined [07:11] *** lichtkind joined [07:14] *** Altai-man_ joined [07:17] *** sena_kun left [07:18] *** softmoth left [07:24] *** Doc_Holliwood joined [07:26] *** xinming_ left [07:27] *** xinming_ joined [07:33] *** dakkar joined [07:33] *** aborazmeh left [07:43] *** rbt left [07:44] *** rbt joined [07:48] *** pecastro joined [07:49] *** k-man_ joined [07:50] *** k-man left [08:01] *** Doc_Holliwood left [08:12] hi, almost-neutral-moritz [08:13] *** xinming_ left [08:14] *** xinming_ joined [08:21] *** ufobat joined [08:26] *** xinming_ left [08:27] *** xinming_ joined [08:38] *** xinming_ left [08:39] *** xinming_ joined [09:12] *** xinming_ left [09:13] *** xinming_ joined [09:15] *** sena_kun joined [09:17] *** Altai-man_ left [09:26] hi El_Che :D [09:26] I'm biased, and I admit it [09:27] pretty much everyone here is a jnthn fanboi, including me :) [09:29] I'm finish watching the talk before commenting (having kids at home that need school guidance is a lot of work, who would have thoough ;). [09:29] so far, the talk was very interesting [09:30] altough on a layer well below where I work :) [09:30] it's interesting to know how it all works [09:35] *** andrzejku joined [09:42] *** Doc_Holliwood joined [09:56] *** wamba left [10:02] for whoever add the combinations array method: thanks! It save me a lot of loops with questionable logic. It's really great. [10:11] *** rbt left [10:11] *** rbt joined [10:18] *** lichtkind_ joined [10:19] *** Doc_Holliwood left [10:20] *** lichtkind left [10:30] *** daxim left [10:35] *** daxim joined [10:45] *** lgtaube joined [10:48] *** Doc_Holliwood joined [10:49] *** xinming joined [10:52] *** xinming_ left [10:58] In case someone tested my SuperMain module: I just fixed those pesky boolean named parameters :) [11:12] *** aindilis left [11:13] *** aindilis joined [11:14] *** Altai-man_ joined [11:17] *** sena_kun left [11:32] *** Doc_Holliwood left [11:46] *** rbt left [11:47] *** rbt joined [12:11] *** raschip joined [12:14] *** epony joined [12:19] *** mensvaga joined [12:28] *** mensvaga left [12:29] *** mensvaga joined [12:42] *** wamba joined [12:44] *** aborazmeh joined [12:44] *** aborazmeh left [12:44] *** aborazmeh joined [13:02] *** Doc_Holliwood joined [13:02] * lizmat drops a pin [13:06] jnthn: I have a question about your RakuAST work. Would it be correct to say it's not really an **abstract** syntax tree if this work goes forward? It would be a concrete syntax tree, wouldn't it? Since I think to be useful it would have to reflect the actual program... [13:09] *** tokomer joined [13:11] to me, it sounds like an abstract syntax tree [13:11] a concrete syntax tree is more like the match object at the end of the parsing stage [13:12] raschip: A concrete syntax tree would always model stuff like whitespace, comments, etc. as well as other details that don't really matter (for example, 100_000 and 100000 would have the same representation in RakuAST). [13:12] at least, going by the answers in https://stackoverflow.com/questions/1888854/what-is-the-difference-between-an-abstract-syntax-tree-and-a-concrete-syntax-tre [13:13] I think there should be a way to retain the other stuff too (although the default will be to discard it) [13:14] Maybe it'll just be realized by exposing the match tree, and RakuAST is attached via. .ast :) [13:15] otoh, that *also* discards whitespce and comments by default. [13:16] *** sena_kun joined [13:17] *** Altai-man_ left [13:18] Right, it would be a not-so-abstract tree. Although Raku already attaches comments to the tree, since it's possible to retrieve them, the part about not representing actual precedence parsing still applies. Thanks jnthn and moritz. [13:21] Would it be correct to say that the CST is what's produced by Perl6::Parser, then? [13:22] It attaches doc comments, but not the rest. [13:22] Yes, I'd say the Match tree counts as a CST [13:26] *** farcas1982regreg left [14:00] *** dakkar_ joined [14:01] *** dakkar left [14:01] *** dakkar_ is now known as dakkar [14:05] *** wamba left [14:11] *** Doc_Holliwood left [14:22] *** melezhik joined [14:41] [Coke]: ummm I'm unable to leave a comment on the RakuAST proposal [14:42] [Coke]: now it requires me to login, so I'm trying to make an account and I can't [14:42] it says that the *name* is already in use, so I can't create a new account [14:42] but I don't think I ever had one [14:43] also, isn't it weird that it considers names to be unique? [14:43] <[Coke]> If you'd like, you can PM me the comment and I'll add it, attributing to you, while we try to get your account set. [14:43] Yes, that is weird. [14:43] <[Coke]> Yup, sounds weird. [14:43] *** ryn1x joined [14:44] *** lucasb joined [14:45] <[Coke]> AlexDaniel: https://github.com/RapidApp/tpf-blog-live/issues - please open a ticket here about issues with the site. [14:45] <[Coke]> (issues that are not content related, like this one.) [14:46] <[Coke]> Please feel free to tag me in the ticket (@coke) [14:46] *** Doc_Holliwood joined [14:48] Since a Channel acts like a queue and is non blocking on to write, this implies some sort of buffered channel implementation... does the underlying data structure have a capacity or buffer size? Or can it grow dynamically and indefinitely? I am wondering if a thread on the receiving end crashed what will happen in the worst case, given another [14:48] thread keeps putting messages onto the channel that never get read. [14:50] I'm pretty sure it can grow dynamically, and gobble up all your RAM [14:50] They work like an Array, which doesn't have a limited size by default in Raku. [14:55] *** aborazmeh left [14:56] *** ryn1x left [14:56] [Coke]: https://github.com/RapidApp/tpf-blog-live/issues/14 [14:58] ryn1x: re Channel: great questions, can you file a ticket somewhere? Raku/doc maybe? [14:58] AlexDaniel, I'll pass your message to ryn1x [14:58] *** ryn1x joined [14:58] ok thanks [14:58] 2020-04-20T14:58:10Z #raku ryn1x: re Channel: great questions, can you file a ticket somewhere? Raku/doc maybe? [14:58] *** melezhik left [15:02] *** ryn1x left [15:02] <[Coke]> AlexDaniel: Thanks. Probably an issue with the rollover from the previous software. [15:02] *** Altai-man_ joined [15:02] <[Coke]> I had an issue where I had no name set, I think, and things got confused. [15:03] [Coke]: tbh I don't know if I have an account or not… I don't think I do [15:03] <[Coke]> Sure, could be anything. Again, happy to post a comment for you in the meantime. [15:05] *** sena_kun left [15:08] *** molaf left [15:12] *** softmoth joined [15:26] *** ufobat_ joined [15:28] *** tokomer left [15:29] *** kenshiro joined [15:29] *** kensanata left [15:30] *** ufobat left [15:38] *** raschip left [15:39] *** MasterDuke left [15:49] *** rbt left [15:49] *** MasterDuke joined [15:50] *** rbt joined [15:53] *** Actualeyes joined [15:53] [Coke]: https://gist.github.com/AlexDaniel/70d7b3e5a28a8cbdae5c7344b1d40d3c [15:54] *** cpage_ joined [15:56] *** cpage left [15:56] *** cpage_ is now known as cpage [16:03] *** AlexDaniel left [16:08] The I'm feely lucky button on modules.raku.org is broken and points to this: https://modules.raku.org/dist/. I don't know who maintains it. [16:10] <[Coke]> AlexDaniel`: added [16:10] *** Doc_Holliwood left [16:12] *** AlexDaniel joined [16:12] [Coke]: thanks! [16:13] *** AlexDaniel left [16:13] *** AlexDaniel joined [16:13] <[Coke]> thank you for the feedback. Always good to hear from the community when processing grants. [16:18] *** melezhik joined [16:25] *** Doc_Holliwood joined [16:38] *** stoned75 left [16:38] *** dakkar left [16:43] *** chloekek joined [16:51] *** melezhik left [17:03] *** sena_kun joined [17:05] *** Altai-man_ left [17:10] *** andrzejku left [17:27] *** abraxxa left [17:29] *** colomon___ left [17:31] *** colomon_ joined [17:32] 17° and windy outside with the window open is so cozy. [17:32] 2020-04-18T19:08:28Z #raku chloekek: I just saw your issues re printf. See my comments there, not sure if you'd want to collab on a projec there, but I'd be happy to help work on it. [17:32] 2020-04-20T14:06:11Z #raku-dev chloekek https://crai.foldr.nl doesn't show Camelia anymore, but still references it in the footer :-) [17:33] lizmat: Camelia is still on the cardboard box. I plan to put it larger on the home page though. [17:33] :-) [17:37] *** Maylay left [17:40] *** kenshiro left [17:43] so, I'm completely without inspiration for a presentation on the Conference in the Cloud: https://perlconference.us/tpc-2020-cloud/ [17:43] maybe it would be an idea to set up a repo with presentation suggestions ? [17:51] New module released to CPAN! Test::Async (0.0.2) by 03VRURG [17:51] *** MasterDuke left [17:51] lizmat: can't we use an existing one? Like marketing, for example. [17:52] vrurg o/ [17:52] yeah, sure... [17:52] o/ :) [17:53] I wonder if the first round of submissions has been considered already. I've got no reply to mine. [17:53] did you submit for the in-person, or the cloud one, or both ? [17:54] lizmat: I was also thinking maybe we could keep a list of presentation recordings on https://raku.org/resources/ [17:54] chloekek: feels like a good idea [17:55] lizmat: both. [17:55] *** softmoth left [17:56] hmmmm [17:56] The in-person has been accepted. [17:56] *** softmoth joined [18:04] *** Maylay joined [18:05] vrurg: I haven't had my cloud talk accepted yet either [18:05] *** sjm_uk left [18:06] guifa2: thanks! Then it most definitely means they're very busy what could be well-explained with totally new format they try to handle. [18:11] vrurg: indeed. but I would imagine anyone whose talk was already accepted for in person will get accepted for the cloud version [18:14] *** melezhik joined [18:19] *** MasterDuke joined [18:21] *** sauvin left [18:29] guifa2 vrurg I'm told you should be receiving confirmation either today or tomorrow [18:30] so keep your fingers crossed! :-) [18:32] *** colomon_ left [18:34] *** softmoth left [18:35] *** softmoth joined [18:40] lizmat: not fair cheating with inside info haha [18:40] *** iviv joined [18:41] doesn't always work :-) [18:41] *** sjm_uk joined [18:47] *** molaf joined [18:49] *** molaf_ joined [18:52] *** molaf left [18:53] *** Actualeyes left [18:53] and another Rakudo Weekly News hits the Net: https://rakudoweekly.blog/2020/04/20/2020-16-rash-in-progress/ [18:56] *** sjm_uk left [19:02] *** Altai-man_ joined [19:05] lizmat: I have a correction: there is a new module, Test::Async. Another matter, I forgot to change 'production' status to true while publishing. [19:05] *** sena_kun left [19:06] if it's not on CPAN, I don't see any updates [19:07] Ok, will go in for this week then. :) Anyway, I messed up with META... [19:07] New module released to CPAN! Test::Async (0.0.3) by 03VRURG [19:08] yup, next week! [19:08] *** cooper left [19:09] *** chloekek left [19:10] *** cooper joined [19:13] *** Black_Ribbon joined [19:14] *** melezhik left [19:20] *** chloekek joined [19:32] lizmat: I think parsing COBOL is straightforward. The trickiest bits are in fixed form directives, line continuations etc. Expressions and statements are simple rules for which compiler vendors provide EBNF for all the dialects they support (as well as the standard, but it doesn’t specify dialects that are widely used). [19:33] *** mowcat joined [19:33] The biggest problem with implementing COBOL would be that 1) it has very many constructs, 2) the way it operates on data is with very specific rules that are unusual in today’s languages, such as decimal wraparound, and 3) performance is a concern for most deployed programs. [19:37] I understand that a lot of COBOL programs nowadays run on simulated hardware [19:37] so running something closer to the metal, may work, or not? [19:38] The simulation is probably more so in terms of I/O devices. [19:42] *** zostay joined [19:46] I only have surface-level knowledge of mainframes. They have a different architecture from personal computers and rack servers, with different I/O- and computation trade-offs. Running your optimized transaction processor on MoarVM on an IBM Z will not do you any good in terms of performance, unless MoarVM learns how to generate code for mainframe architectures. [19:47] But if you have a COBOL app that you run on a JVM (e.g. with Micro Focus) and want to attract Perl or Raku programmers, sure. :) [19:47] *** colomon_ joined [19:48] *** rainmanjam joined [19:48] I think the whole point of a COBOL exercise on Raku, would be the capability of running COBOL programs outside of mainframes ? [19:49] That’s already possible with GnuCOBOL and various commercial compilers. [19:49] ah, ok, that just goes to show how much I know of that area :-) [19:49] In fact, I added GnuCOBOL to glot.io a while back :) https://glot.io/new/cobol [19:50] It would sure be fun though. I once attempted to implement COBOL and got some very basic programs working. It compiled to JS, because that’s what you do. [19:52] https://glot.io/snippets/fmov67aipd [19:52] *** rbt left [19:53] *** rbt joined [19:53] cool [19:54] COBOL data types are like Cool. :) [19:55] Having a Raku slang for just COBOL picture clauses would be neat. [19:56] PIC X(20) #`[ 20-character string. ]; PIC 99V99 #`[ 4-digit unsigned number. decimal point in the middle, except when doing unformatted I/O ] [20:00] *** andrzejku joined [20:16] Also kudos for sending Raku weekly in an email that can also be viewed without HTML support. :) [20:16] chloekek: you need to thank Wordpress for that [20:16] *** mowcat left [20:17] WordPress++ [20:17] *** mowcat joined [20:38] Are there any examples out there of how to make a Grammar give useful error messages when something does not match? [20:38] I found `FAILGOAL`, but haven't figured out how to properly use it [20:39] <[Coke]> Grammar::Debug ? [20:39] Hm, I'm thinking more from the user's perspective [20:39] <[Coke]> or, not for you, for the user? [20:39] So not debugging the Grammar, but the input, if that makes sense [20:39] <[Coke]> ah [20:39] <[Coke]> ;) [20:40] <[Coke]> yup. In general, the examples I've seen mean you have to add alternatives everywhere which die with the helpful error. [20:40] <[Coke]> but I'd wait for someone else to answer. :) [20:40] :D [20:41] I guess the Raku grammar might be a good place to look, but I was hoping for something less daunting [20:45] jjatria: The technique described by [Coke] is what's done generally [20:45] So if you expect a letter or a number, and anything else would be an error: [20:45] <[Coke]> \o/ [20:46] token foo {  || || { die "You have a problem here" } } [20:47] A common way of disallowing a character / token is to use [  {die} ]? [20:48] If doesn't match, no harm done because it never gets to die because the group is optional. [20:48] Ah, cool, that's useful [20:49] That's the kind of thing I was looking for, examples of how these things look when implemented. Thanks! [20:52] jjatria: take a look at this definition for some stuff: [20:52] https://gist.github.com/alabamenhu/7e30eecaf09db3e3a6d68024518e378d [20:52] *** andrzejku left [20:53] Thanks! [20:57] That's one I just did for the binary grammar's grammar. It expects things in the format b0000_0000 or o00_00 or x00 (if 8 bit), but also unlimited underscores inside the token (so x_________f___8 is valid, but x56_ is not). [20:58] Right shifting with X is only allowed terminally, so that might help understand what's going there [21:03] *** sena_kun joined [21:05] *** Altai-man_ left [21:09] *** mowcat left [21:11] *** andrzejku joined [21:15] *** andrzejku left [21:18] *** chloekek left [21:36] *** softmoth left [21:50] *** rindolf left [22:09] *** melezhik joined [22:09] "The iterator of this Seq is already in use/consumed by another Seq" is one of the more annoying errors [22:11] *** melezhik left [22:15] jdv79: if you have a golf, we can either say what's wrong with your code, or that it is a bug :) [22:15] sleep& [22:16] it just pops ups from time to time and i know mostly why it happens but its awfully unintuitive for newbies [22:16] i can't golf it atm, sorry [22:18] is some ways the diff tween array and scalar assignment are whack [22:19] jdv79: yeah, getting Seqs is pretty much always unexpected, it's just that most of the time it's a pleasant surprise [22:19] i realize its got cleverness and utility but does it strike a good balance overall - maybe [22:21] kind of similar in my mind to Scalar. most of the time you can ignore it and its all nice but sometimes the abstraction bites and seemingly out of nowhere if you're pleasantly otherwise oblivious to what's under teh covers [22:21] sometimes I'd have a bunch of code that does all kinds of processing, and then I'd be like “oh, it'd be nice if this was lazy so that it doesn't process a bunch of stuff needlessly” [22:21] and then I look and it turns out that it's Seqs all the way through and I don't need to change anything [22:22] yeah, i know there's goodness. i'm just remarking on the rough edges that poke out here and there [22:24] i'm trying to think how i could introduce raku at $work and its stuff like that where i'd have trouble justifying or even just explaining it to my colleagues. [22:24] *** softmoth joined [22:30] *** softmoth left [22:35] Hi guys! is that a bug? [22:35] m: sub a([$a]) { dd $a }; a [1]; a [1 => 2] [22:35] rakudo-moar b0a720cb6: OUTPUT: «1␤Too few positionals passed to 'a'; expected 1 argument but got 0 in sub-signature␤ in sub a at line 1␤ in block at line 1␤␤» [22:36] m: sub a([|$a]) { dd $a }; a [1]; a [1 => 2] [22:36] rakudo-moar b0a720cb6: OUTPUT: «5===SORRY!5=== Error while compiling ␤Obsolete use of | or \ with sigil on param $a␤at :1␤------> 3sub a([|$a7⏏5]) { dd $a }; a [1]; a [1 => 2]␤ expecting any of:␤ shape declaration␤» [22:39] sub signature... [22:45] *** Doc_Holliwood left [22:50] *** Kaiepi left [22:50] *** Kaeipi joined [22:52] *** Kaeipi left [22:52] *** Kaeipi joined [23:02] *** Altai-man_ joined [23:05] *** sena_kun left [23:09] *** aborazmeh joined [23:09] *** aborazmeh left [23:09] *** aborazmeh joined [23:19] *** cpan-raku left [23:20] *** cpan-raku joined [23:20] *** cpan-raku left [23:20] *** cpan-raku joined [23:23] *** lucasb left [23:31] SmokeMachine: I think it's spec'd semantics of List.Capture [23:31] Though I ain't sure I like them :) [23:31] The pair promotion to named arguments seems to be a trap more often than it's useful [23:32] I'm not sure what *else* relies on this behavior, however. [23:33] jnthn: and that, even doing “1” => 2 or (1 => 2) will not fix the problem as when you are trying to receive a Pair... [23:33] *** melezhik joined [23:33] *** melezhik left [23:33] m: sub foo(Pair $p) { dd $p }; foo (1 => 2) [23:33] rakudo-moar b0a720cb6: OUTPUT: «1 => 2␤» [23:33] m: sub foo(Pair $p) { dd $p }; foo 1 => 2 [23:33] rakudo-moar b0a720cb6: OUTPUT: «1 => 2␤» [23:34] m: sub foo(Pair $p) { dd $p }; foo bla => 2 [23:34] rakudo-moar b0a720cb6: OUTPUT: «Too few positionals passed; expected 1 argument but got 0␤ in sub foo at line 1␤ in block at line 1␤␤» [23:34] m: sub foo(Pair $p) { dd $p }; foo “bla" => 2 [23:34] rakudo-moar b0a720cb6: OUTPUT: «5===SORRY!5=== Error while compiling ␤Unable to parse expression in curly double quotes; couldn't find final '”' (corresponding starter was at line 1)␤at :1␤------> 3b foo(Pair $p) { dd $p }; foo “bla" => 27⏏5␤ …» [23:34] m: sub foo(Pair $p) { dd $p }; foo (“bla" => 2) [23:34] rakudo-moar b0a720cb6: OUTPUT: «5===SORRY!5=== Error while compiling ␤Unable to parse expression in curly double quotes; couldn't find final '”' (corresponding starter was at line 1)␤at :1␤------> 3foo(Pair $p) { dd $p }; foo (“bla" => 2)7⏏5␤ …» [23:34] Well, yes, by the time it's in a List then the syntactic distinction is long gone. [23:34] m: sub foo(Pair $p) { dd $p }; foo ("bla" => 2) [23:34] rakudo-moar b0a720cb6: OUTPUT: «:bla(2)␤» [23:34] m: sub foo(Pair $p) { dd $p }; foo (bla => 2) [23:34] rakudo-moar b0a720cb6: OUTPUT: «:bla(2)␤» [23:34] m: sub foo(Pair $p) { dd $p }; foo "bla" => 2 [23:34] rakudo-moar b0a720cb6: OUTPUT: «:bla(2)␤» [23:35] m: sub foo([Pair $p]) { dd $p }; foo ["bla" => 2] [23:35] rakudo-moar b0a720cb6: OUTPUT: «Too few positionals passed to 'foo'; expected 1 argument but got 0 in sub-signature␤ in sub foo at line 1␤ in block at line 1␤␤» [23:35] jnthn: are you thinking of maybe changing it? [23:35] I mean, you can have the other thing, so long as you accept that if you do `foo [bla => 2]` then you're going to get a positional, not a named. [23:36] m: sub foo([:$bla]) { dd $p }; foo [bla => 2] [23:36] jnthn: I don’t know if that would be the intent most of the time… but that was my intent this time... [23:36] rakudo-moar b0a720cb6: OUTPUT: «5===SORRY!5=== Error while compiling ␤Variable '$p' is not declared␤at :1␤------> 3sub foo([:$bla]) { dd 7⏏5$p }; foo [bla => 2]␤» [23:36] m: sub foo([:$bla]) { dd $bla }; foo [bla => 2] [23:36] rakudo-moar b0a720cb6: OUTPUT: «2␤» [23:36] So you'd break that. [23:37] I suspect, in hindsight, the behavior we ended up with creates too much of a discontinuity [23:37] m: sub foo([*%a]) { dd %a }; foo [bla => 2] [23:37] rakudo-moar b0a720cb6: OUTPUT: «Hash element = {:bla(2)}␤» [23:37] Yup, that one'd break too [23:38] Otoh, Capture promotion would be much cheaper if we didn't scan for Pair [23:38] In fact, you might even be able to elide the coercion completely in some cases, which'd be better for performance too. [23:39] So it's at least worth thinking about changing it [23:39] on my case, I was wanting to receive something like: 1 => [2 => [4, 5], 3 => [6, 7]], my signature was: (Pair (Int :$key, :value([$left, $right?]))) [23:40] changing it, that would work, right? [23:41] Yes [23:42] and would that make sense to not search Pairs on sub signature but continue doing that on signature? [23:42] Oh! you was saing onli inside List! [23:42] s/onli/only/ [23:42] Nothing specific to signatures would actually change [23:42] It's the behavior of List.Capture that we're considering [23:42] List.Capture, right? [23:43] yes [23:43] Any type can implement method Capture to choose how it is going to destructure in a Signature. [23:43] I think, on this case, that would make completely sense... [23:44] that’s a interesting information.. I’ve never thought about implementing a Captue method… that could be useful... [23:44] jnthn: would you mind if I change the subject for a second? [23:45] If you've a moment to make a problem solving ticket on List.Capture, please do [23:45] What else? :) [23:45] I was thinking… on your macro proposal, would it be able to do something like method macro? [23:46] I mean, would that be possible do on Red, a ResultSeq.map be a macro? or could it have access to the RakuAST somehow? [23:46] I’m going to create the ticket [23:48] Well, the trouble there is that nethod dispatch is late-bound, whereas macros happen at compile time, so the direct answer is "no"... :) [23:49] *** pecastro left [23:49] However, there's probably - with a bit more work - a way to make this happen. [23:49] Well, to make you able to get the AST [23:50] I would really like to have a `method map(&block)` and get the RakuAST of that &block... [23:50] I can see two ways to do it [23:50] Hum...? [23:52] 1) I speculated in my recent talk that we'll be able to have custom compiler passes, which will be fed the entire AST of the compilation unit to process. If you can do enough type-tracking to always know when you're doing something against a Red collection, then you could arrange for the AST to be preserved anyway. Heck, you could even walk it at compile-time and make sure it's something you know how to turn into SQL, and do some of the translation [23:53] 2) Or the bigger hammer is to have a way to force AST preservation on all method calls of a certian name, using the same technique, and then some way to make it "contaigious" on all using modules. [23:54] Or the less likely option 3) is that we decide that the AST is always preserved for all compiled code, but that's a lot of memory/disk overhead... [23:54] *** lichtkind_ left [23:55] Option 1 is neat in that you can actually tell people at compile time when they do something with no SQL mapping, not at runtime. Which would fix the LINQ problem where one didn't know until runtime. [23:55] (I assume it's still that way, I didn't do .Net for years...) [23:55] *** rbt left [23:56] transforming that into a custom code that would know how to do the SQL at compie time would be great… but the custom compiler passes is not planned to the 1st step, right? [23:56] *** rbt joined [23:57] Not really, but it's probably the easiest of all the things I'd proposed to defer [23:58] I suspect it's easy to implement, and the work is in the API design. I'd be happy to look at proposals. [23:58] so I could hope to something make it first step? [23:59] Hum… proposals… that would be interesting… is there any file you would suggest me to start looking at? [23:59] Not really; the things you'd be best looking at don't exist yet :)