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.
nine japhb: that makes me wonder: how does the old compiler frontend handle nqp ops in the first place? 06:53
Nicholas good *
"lex, yacc, smoke and mirrors" ? :-) 06:54
nine That's not that far off actually :D token term:sym<nqp::op> 06:58
And japhb++ is correct as well. The old frontend emits QAST::Want nodes for those literals. Actually the new one does as well, with just one exception: constant folded (double) quoted strings. So it's an omission rather than a conceptual issue. 07:02
nine A longname is a name + optional colonpairs. My first instinct for the AST representation would be class RakuAST::LongName is RakuAST::Node { has RakuAST::Name $.name; has %.colonpairs; ... }. 12:18
However RakuAST::Type::Simple and other places expect a RakuAST::Name for the name, not such a LongName. This indicates that RakuAST::Name should be an abstract role rather than the class it is now. 12:19
Alternatively RakuAST::Name::Long could be a subclass of RakuAST::Name. Would take care of those type constraints, but makes it somewhat cumbersome to construct (since $<name>.ast already creates a RakuAST::Name) which may be a sign that this isn't the right way either. 12:20
jnthn RakuAST::Name is what goes with LongName 12:22
*longname
It's meant to have colonpairs included too eventually 12:23
I don't think there's any reason to distinguish name vs. longname in the AST level; almost everywhere accepts a longname anyway
So no subclass, just add colonpairs in RakuAST::Name 12:24
nine Ah, that's good to know :)
jnthn For things like TypeName:D and Type(OtherType) I was thinking of RakuAST::Type::Definedness and RakuAST::Type::Coercion, fwiw
(Which would reference other RakuAST::Type nodes) 12:25
nine So "# TODO add colonpairs" is quite accurate then despite its brevity. I.e. get an object from $<name>.ast and then .add-colonpair those colonpairs 12:26
class RakuAST::Type::Coercion is RakuAST::Type is RakuAST::Lookup is already implemented :)
github.com/rakudo/rakudo/commit/27...78d07ccfd6 12:27
jnthn Ah, nice :) 12:31
nine Interesting: the old compiler frontend emits QAST::Op(istype_nd) with Int followed by QAST::Op(isconcrete_nd) for an Int:D param. My current state emits QAST::Op(istype_nd) with Int:D instead, but that still seems to do the right thing 13:58
Any reason to do istype_nd+isconcrete_nd instead?
nine sub group-of ( Pair ( Int:D :key($plan), Pair :value(( Str:D :key($desc), :value(&tests))))) # sometimes I wonder if we've taken things too far 14:35
jnthn I think the istype + isconcrete pair are cheaper 14:36
Unless there's already dispatcher handling to do better on definedness types 14:37
But by default it'll call accepts_type method on the meta-object, iirc 14:38
nine # Do type checks. 15:09
# TODO really more involved than this 15:10
Indeed :D