[06:35] *** Altai-man joined [06:36] *** Altai-man left [06:39] *** Altai-man joined [09:22] *** lizmat left [09:23] *** lizmat joined [09:23] *** TempIRCLogger__ joined [09:25] *** TempIRCLogger left [10:17] *** Xliff joined [10:17] \o [10:20] jnthnwrthngtn: Good morning. Have a question about RakuAST, but you aren't in the Raku channels at the moment. Mind if I ask this, here? [10:25] Well, I deciced to gist it: https://gist.github.com/Xliff/bc5f7277d0fec4ae78d1d37649d1ce76 [10:28] interesting question :-) [10:30] Yep. Was actually pretty fun to write, once I figured out a few things. [10:31] Still, large scale RakuAST would be better if I had the raku to start with and could then parse it down into RakuAST, somehow. [10:32] Almost wonder if I could pull the grammar from the MAIN language braid and use that. [10:32] Xliff: if you look at the test files, I think you will find examples of source being converted to ASTs ? [10:33] in fact, it is part of the Deparse tests, to see whether they roundtrip [10:36] Would those be found in t/12-rakuast? [10:38] lizmat: Actually, those tests originate from the RakuAST representation, not Raku. [10:39] hmmm... [10:40] but isn't that what EVAL returns if you switch on the RakuAST grammar ? [10:40] the tests should work either way, no ? [10:42] Xliff: I'm trying to work out which of two questions you're asking, but then realized you may not be sure :D [10:42] Anyway, there's two things [10:43] OK [10:43] 1. Yes, it'd be desirable if there's an API in Raku where you give it source code and it gives you back RakuAST. I didn't really design this yet, but agree it should exist. [10:44] 2. I don't think that's actually what you want, though, because then you'd have strings of Raku code. I think quasi quotes are more what you're looking for. [10:44] Was looking for #1, but would be interested to hear about #2 [10:45] A quasi is a way to quote a bit of Raku code such that you get back the AST fo it [10:45] *of it [10:45] So instead of RakuAST::IntLiteral.new(42), you would write `quasi { 42 }` [10:47] There are also unquotes, so if you had $ast-a and $ast-b, you could instead of `RakuAST::ApplyInfix.new(infix => RakuAST::Infix.new('+'), left => $ast-a, right => $ast-b)` write `quasi { {{{$ast-a}}} + {{{$ast-b}}} }` [10:47] OK! I like that. [10:47] In general: while quasis have been talked about primarily in the context of macros, with RakuAST they're useful outside of them too. [10:48] I'm interested in RakuAST to provide a more maintainable way to hande a lot of existing code in my GLib projects [10:48] That bit in the gist is a part of that work. [10:49] My expectation is that folks writing parsers that compile stuff into RakuAST might find the OO API (constructing AST objects) more comfortable, but folks doing stuff along the lines of what you showed will find quasi quoting far more convenient. [10:49] So it looks like role composition is still unaddressed, so I [10:49] I've gone as far as is supported. [10:50] And I may just find quasi blocks very useful in that. [10:50] I'll get back to RakuAST stuff once new-disp is landed :) [10:50] Fair enough. I expected no less. Your new-disp stuff has been fascinating. [10:50] At any rate, thanks for the answers! [10:50] Welcome :) [10:51] Also I think I owe you at least one PR review on cro-webapp [10:51] Yeah. I had to pull a fix. Come to think of it... I might want to get back on that! LOL! [11:02] jnthnwrthngtn: Consider the this jsFiddle -- https://jsfiddle.net/rzaceg8v/ [11:02] Having the trailing 'Z' at the end cause the second field to not work. [11:02] The first works fine with the trailing 'Z' removed. [11:04] *sigh* proper fiddle is here: https://jsfiddle.net/mwku48o2/ [18:08] *** patrickb joined [19:16] *** patrickb left [19:43] *** Xliff left