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.
00:00 reportable6 left, kjp left, kjp joined 00:01 reportable6 joined 03:23 Kaiepi left 03:55 Kaiepi joined 04:50 vrurg_ joined 04:53 vrurg left 06:00 reportable6 left 06:02 reportable6 joined 07:16 Kaiepi left 08:03 sena_kun joined 09:24 sena_kun left 09:25 sena_kun joined 09:31 epony left 09:55 sena_kun left 11:13 squashable6 left 11:15 squashable6 joined, Kaiepi joined 11:22 sena_kun joined 12:00 reportable6 left, reportable6 joined 13:12 Kaiepi left 13:15 Kaiepi joined 13:49 sena_kun left
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2023/01/02/2023-...ming-away/ 13:57
14:25 vrurg_ is now known as vrurg
vrurg While playing around with implementing roles for RakuAST, I came across a crazy idea that they can be implemented in Raku instead. 14:27
s/they/RakuAST/
14:35 sena_kun joined
SmokeMachine Talking about RakuAST, do we have a way to implement custom compiler passes already (officially or not)? 14:35
vrurg SmokeMachine: I thought you were asking already and Jonathan replied. Anyway, not yet. Not officially. 14:40
In theory, you could try mixing in a role into Perl6::Compiler object and use `addstage`, method, but I'm unsure it'd work. 14:41
15:35 linkable6 left, evalable6 left 15:36 linkable6 joined, evalable6 joined
SmokeMachine vrurg: I'll give it a try, thanks! 15:37
vrurg: how could I get Perl6::Compiler? it doesn't seem $*RAKU.compiler is that... :( 16:21
vrurg SmokeMachine: no, it isn't. You need nqp::getcomp('Raku'). But you better traverse src/main.nqp and the Compiler.nqp itself for details. 16:24
SmokeMachine vrurg: I was looking at that... and it doesn't seem to save $comp anywhere... :(
vrurg: thanks 16:26
vrurg SmokeMachine: welcome! But that's why I added Perl6::Compiler to the list. It inherits from HLL::Compiler and this is where the magic happens. Many things are done by NQP code. 16:27
I just wasn't sure where exactly the binding takes place, just have found it. 16:28
vrurg is afk 16:33
16:45 epony joined
SmokeMachine it seems NPQClassHOW has no BUILD_LEAST_DERIVED... :( 17:18
nine SmokeMachine: taking a few steps back, actually what do you want to use that custom compiler pass for? 17:25
SmokeMachine nine: I want to start studying how I'll use RakuAST to convert Raku code to SQL on Red 17:26
nine That sounds more like a use case for macros 17:27
SmokeMachine nine: probably not, because I'll have to, having a code like `Bla.^all.grep({ .column1 <= 3 })`, I'll have to convert the block inside grep 17:29
Voldenet You can just execute the block immediately 17:32
SmokeMachine nine: I'm thinking in (if possible), create a new attraction to Block, and run a custom pass to add the ast of each block inside grep/map/first/etc. to that attribute and on my custom grep/map/first/etc, if there is RakuAST on that attribute, convert that to Red::AST and use that
Voldenet: sorry, I don't get it 17:33
Voldenet .column1 could return field reference, `<=` op could accept FieldReference and Int 17:34
so it would look like a normal lambda, but it would be extremely weird lambda
SmokeMachine that's kind of I currently do...
but I'd like to "simplify" that just converting RakuAST to Red::AST... 17:35
nine But that's exactly what macros are supposed to give you: look like functions, but instead of executing that code they get the AST and can manipulate it 17:36
SmokeMachine nine: but I need methods and not functions...
nine Well since macros aren't implemented yet, we don't know that they won't be able to look like methods. An easy workaround would be something like Bla.^all.grep(sql { .column1 <= 3 }) though 17:40
SmokeMachine Voldenet: currently I have all these operators (github.com/FCO/Red/blob/master/lib...ators.pm6) that returns Red::AST and all Red::AST in "boolean context" throw control exceptions (github.com/FCO/Red/blob/master/lib...6#L28-L33) that allow me "discover" (github.com/FCO/Red/blob/master/lib...6#L56-L96) what it does...
nine: but the intent is just look like Black.^all is just a regular Seq (its a ResultSeq) 17:41
nine: Red already works as if it was a regular Seq... I just wanted to simplify my logic that converts a Block to Red::AST 17:44
nine Well fair enough. That's obviously your design choice and I won't argue against that, even though I think it's just plain wrong. 17:46
SmokeMachine nine: now I'm curious why you think that's wrong 17:47
Voldenet SmokeMachine: the way I'd use would be entirely different though, I'd not execute any real code, but treat argument to the lambda as expression builder entirely 17:49
nine I think so because I have been totally disillusioned by years of struggling with DBIx::Class and other ORMs. At some point the query just gets complicated enough that it just won't fit anymore into the programming language's model. So I first struggle to get the query working in SQL and then struggle again by translating that to the ORM's syntax. At that point I inevitably wonder what I gain by using that 17:50
ORM in the first place.
17:52 Kaiepi left
nine Replacing SQL with any other syntax is just an exercise in "make easy things even easier and hard things impossible". 17:52
SmokeMachine Voldenet: that way, something like this wouldn't work: Bla.^all.grep: { .a > .b || .c == 3 }
nine: my intent with Red is make you don't need to think in SQL, but you think in Raku Seqs and Red makes the SQL for you (it's still far from doing that for all possible queries and even farther from doing it the best way). But I don't even plan doing all SQL possibilities to Red, but do all Seq manipulation options... 17:55
(ok, maybe a few of SQL options...) 17:56
18:00 reportable6 left 18:02 reportable6 joined
nine And that's precicely the ORM trap: you start using an ORM in your app because it makes doing the trivial queries so easy but later you suddenly run into the wall because the ORM just doesn't support the complicated features you need for your more interesting queries. Or it does it in a way that tanks your performance. And with database queries that can mean that instead of a second your query runs for 18 18:03
hours. 18:04
SmokeMachine nine: but if you need it, you can always use SQL for those complicated queries... 18:10
Voldenet SmokeMachine: eh, you're right, || doesn't work like a normal operator here 18:11
SmokeMachine Voldenet: (I have tried that before going to the way I did) 18:12
nine SmokeMachine: a fact that Red's docs don't seem to mention? 18:14
SmokeMachine Voldenet: and using Red: www.irccloud.com/pastebin/dtuBVfgo/ 18:15
nine: maybe I have forgotten that... :( but you can always run `red-do { .exec: "SELECT 1" }` if you need 18:16
Voldenet tbh. I think macros would be perfect for this 18:17
SmokeMachine and currently you can also have "views" as models: github.com/FCO/Red/issues/491 18:20
Voldenet: I would agree if I could have a method-macro on my class... 18:21
lizmat nine: do you think it could be easy to create an Str.AST method that would compile the given string using the Raku grammar and just produce the RakuAST::xxx objects ?
nine SmokeMachine: yeah, the point where the ORM says "this is too complicated for me, I'm outta here, you're on your own!"
Voldenet nine: ORMs let you pass parts of the query between functions without manually building a string and let you only define fields to select once, or define context of aggregations and joins once 18:22
nine lizmat: trivial really. That's basically an EVAL with :target<ast>
lizmat ok, lemme work on that then :-)
nine Voldenet: except, as we just saw when the query becomes to complex for the ORM's query syntax. Then you suddenly lose all of that. At the point where you'd need support the most. 18:23
SmokeMachine if we have a Block.AST, it would fix all my problems... :)
Voldenet nine: at which point you start your own ORM built around one specific query… :)
SmokeMachine nine: not if you are using the view way, for example... 18:24
nine No, at which point you realize that any replacement syntax for SQL is doomed to fail as no one has ever come up with one that supports all of SQL's features. And if there was one it would just be as complicated and as hard to learn - with the added drawback that it's not as universally useful as SQL. 18:25
Really all people want is to not have to type out those select lists and joins over and over. And not to have to write code for putting the result data into nice objects. An ORM could do that without limiting the expressiveness of queries. 18:26
jdv all orms ive touched eventually failed me
Voldenet ORMs are just tools to help you not type tons of strings for one update or insert with complex key and fetch related entities easier 18:27
nine The only way I see is to have a real parser for full SQL syntax generating a real SQL AST from that and providing utility methods for automating those tedious tasks.
Voldenet sure, it's not universal for any type of query – I don't see any ORM able to support recursive CTEs still 18:28
jdv are macros necessary for dealing with sql? i thought the regex engine and some oo was enuf, no?
nine Macros can make dealing with SQL nicer by making it look less like strings. But they are not necessary. 18:29
SmokeMachine jdv: macro is not needed to dealing with sql, but for what I need, I need more than macros 18:31
18:32 sena_kun left
SmokeMachine nine: would it be possible to have a method to get a the AST of a block? 18:32
Voldenet prql-lang.org/
jdv ok then:)
Voldenet there's possibilities to make sql less painful
by not forcing repetition over and over 18:33
18:33 sena_kun joined
jdv really though. usually i handwrite the sql i want and then fail to back that into the orm at the time. 18:36
18:36 Kaiepi joined
jdv im with the vietnam view of orms but good luck;) 18:37
Voldenet anyway, ORMs can be enormously useful 18:41
jdv id love to see a rigorous presentation or something on that point 18:44
Voldenet select everything, is, wrong, with, this, syntax from (select sum(thing), is, wrong, with, this, syntax from examples group by is, wrong, with, this, syntax) repetitive join repeats on repetitive.syntax = repeats.itself 18:47
lizmat nine: hmmm... but that would use the Perl6 grammar, I would like to use the Raku grammar 19:26
nine lizmat: that will take care of itself once we switch ;)
lizmat true, but I want it *now* without needing to run under RAKUDO_RAKUAST=1 19:27
because it will be a great debugging aid, at least for me personally :-)
and for anybody doing some serious work on RakuAST or with RakuAST 19:28
and sadly Raku::Grammar|Actions are not exposed 19:30
also: it feels like a lot of the discussions on #moarvm would really belong on a dedicated #raku-rakuast channel 19:35
which I already opened :-)
nine Ostensibly yes. But then while we're all busy with rakuast, there won't be much in terms of MoarVM discussion anyway ;) 19:36
lizmat well, it will at least make things better searchable in the future, in a focused channel 19:37
nine: coming back to my question: would it be a matter of just setting the correct classes in :grammar and :actions 19:38
if so, then the problem is really just getting at Raku::Grammar and Raku::Actions, right ?
nine yes
lizmat do we have an official way of getting at that ? 19:39
or do I need to kludge something up with bindhllsym for now?
jdv i didnt realize this is #moarvm. apologizies. 20:02
leont has been considering building an ORM on top of SQL::Abstract, but it's really difficult to write a good one. 20:03
jdv my thoughts are similar. iirc dbic is built atop sa. 20:04
or... with:) 20:07
lizmat nine: % raku -e 'dd Q/my $a = 42/.AST' 20:23
===SORRY!===
compunitmainline requires an MVMCompUnit
thoughts? suggestions?
nine lizmat: pass :compunit_ok(1) 20:45
lizmat that helps a lot already 20:48
% raku -e 'dd Q/my $a = 42/.AST'
P6opaque: no such attribute '$!do' on type ForeignCode in a RakuAST::CompUnit when trying to get a value
nine Looks like EVAL really wants to run code and refuses to just return the AST 20:50
lizmat aaah... ok
yes, that's it
whe! 20:52
whee! rather :-)
% raku -e 'dd Q/my $a = 42/.AST'
my $a = 42
21:10 Kaiepi left 21:48 Kaiepi joined 22:14 sena_kun left
vrurg lizmat: BTW, Raku::Grammar and Raku::Actions are visible through `use Raku::Grammar:from<NQP>;` 22:42
lizmat sadly, that doesn't work inside the setting :-( 23:40

Powered by Cro and the Raku® Programming Language.

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

Thank you!