🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm
Set by lizmat on 8 June 2022.
nemokosch It seems legit that the result is a List 00:05
ab5tract so I've managed to fix the issue with the where blocks in role signatures, but I've run into another issue that I've been grinding on silently for a while and thought I would share here now in case of insights 06:50
m: my $content = 'role R[::T] { method m {"m"}}; class C does R[Int] {}'; shell Q:scalar<RAKUDO_RAKUAST=1 $*EXECUTABLE -e '$content'> 06:53
camelia ( no output )
ab5tract huh, that's broken on my branch, one second 07:00
wait, no that works fine, sorry. 07:01
it's still only in the case of having the where clause on the role signature: 'role R[Int $x where { $x % 2}] { method m { "m" } }; class C does R[2] {}' 07:03
(not sure why pasting always removes one of the '%' symbols, but anyway)
it fails with: 'No appropriate parametric role variant available for 'R': Lexical with name '$?CLASS' does not exist in this frame' 07:04
it's failing at the specialize step in ParametricRoleGroupHOW 07:06
I've tried every approach I can think of to get that $?CLASS into frame here and so far, no luck. 07:07
in the old frontend there is a whole step for fixing up the QAST for role bodies. I wonder if this might somehow be related 07:24
lizmat well, afaik in the Raku grammar the QAST twiddling is handled by generating a RakuAST tree and have the "normal" QAST handling of that, handle the role stuff 07:47
ab5tract but the QAST twiddling I'm talking about takes place in $*W 08:18
oh, in Perl6/Actions, sorry 08:21
"sub begin_time_lexical_fixup" 08:22
lizmat nine might know
ab5tract the elusive Mr. nine :) 08:36
come back man! 08:37
Geth rakudo/main: e08eadf672 | (Elizabeth Mattijsen)++ | src/Raku/ast/operator-properties.rakumod
Add operator properties for some missing (dummy) infixes
 08:55
rakudo/main: 73d02cc0f5 | (Elizabeth Mattijsen)++ | src/core.c/OperatorProperties.rakumod
Add setting of operator properties for infixes

that seemed to have been forgotten before.
rakudo/main: 8dc2e53eef | (Elizabeth Mattijsen)++ | 5 files
RakuAST: have the expression parser use OperatorProperties

  - remove the ::Assign::Item class
  - introduce ::Assignment class, a subclass of ::Infix, taking an
   :item named argument indicating whether item assignment precedence
   is needed. Defaults to list assignment precedence.
  - better handle ternaries in grammar / actions
... (9 more lines)		 09:35
lizmat *phew* that was a lot more work and puzzle fixing that I anticipated 09:36
(than 09:40
ab5tract: I just realized that all of the pipe ops aren't implemented yet in the Raku grammar 10:00
==> <== ==>> <<==
perhaps something to look at to stop the headbanging on roles?
nemokosch ==>> was never implemented, or? 10:12
lizmat ah, could be, but the op is in the legacy grammar 10:13
m: 42 ==>> 666
camelia ===SORRY!=== Error while compiling <tmp>
==>> feed operator not yet implemented. Sorry.
at <tmp>:1
------> 342 ==>> 666⏏<EOL>
lizmat so that would be a *very* easy win :-)
nemokosch :DDD 10:14
Geth rakudo/main: 2b36f85fda | (Elizabeth Mattijsen)++ | src/Raku/ast/operator-properties.rakumod
Add OperatorProperties for ==> and friends
 10:32
rakudo/main: c7338f9675 | (Elizabeth Mattijsen)++ | src/Raku/ast/pair.rakumod
RakuAST: make sure ::ColonPair has operator properties

This seems to be needed for some types of adverb handling		 11:44
rakudo/main: e8076ae415 | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: fix final use of prec hashes

  - add helper method "properties-for-node" which also does error
   checking and has one ad-hoc check for adverb handling
  - use that helper method where it's needed
  - remove debug code: it appears to have done its work
Geth rakudo/main: c035db23d4 | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: remove the %methodcall hash

First of many similar commits for bisectability		 11:51
rakudo/main: 95dbd6cd82 | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: remove the %autoincrement hash
 11:59
ab5tract thanks for the recommendation :) 15:04
I could probably use a break from all of this headbanging, it's true
lizmat: seems like you are pretty far along the path to removing HLL::Grammar 15:09
lizmat yes, I am :-) 15:32
ab5tract it's been impressive to watch the progress 15:33
vrurg It would also be very helpful in some distant future to implement self-bootstrapping of Rakudo. 15:35
lizmat yes, that's also at the back of my mind
ab5tract now that would be something 15:36
lizmat indeed it would: let's first try to build the setting with the Raku grammar :-) 15:37
ab5tract yeah, that's a big enough tower to tackle for now :) 15:40
the feed operators... I'm not quite sure where to place the class(es) in the RakuAST hierarchy. Woul dthey fall under expressions? Unless I can use RakuAST::Infix directly... 15:45
lizmat I'm not sure... feels like at least initially they could be just infixes.... 15:46
Geth rakudo: ab5tract++ created pull request #5373:
RakuAST: Role signature fixups		 15:48
ab5tract huh, intriguing.. it can't seem to resolve the lexical `infix:sym«==>»` .. shouldn't that come from the setting? 16:29
lizmat nope: there is no actual operator for it, it's purely a grammar structure 16:31
surprised me as well :-)
Geth rakudo/main: 310e40dabc | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp
RakuAST: remove O-logic from meta ops

It feels that this *could* mean it is getting the wrong precedence somewhere, but removing these lines doesn't break any tests, so glad to do it this way for now, and as a separate commit for easier bisectability		 16:40
ab5tract oh, ok, that's definitely intriguing... and it sounds like it will need its own expression class 16:44
lizmat if I look at the QAST of the feed op in the legacy grammar 16:50
e.g. for:
1,2,3 ==> my @a
the it looks like it is generating the same QAST as for:
my @a <== 1,2,3
which is basically: 16:51
(my @a).append(1,2,3)
if I'm reading correctly :-)
so maybe an ordinary infix, with an ApplyFeed class ? 16:52
ab5tract the ApplyFeed makes perfect sense.. I'm not sure what you mean about "ordinary infix" though. IIUC: If I try to make an infix object without a resolvable infix subroutine, it will die when it gets visited 17:11
lizmat hmmm.... then maybe a RakuAST::Feed class, that *could* be a subclass of Infix 17:13
with its own QAST logic ?
I'm just spitballing here 17:14
nemokosch this is actually a good example of when some deliberate design would be appropriate 17:15
- does it matter if there is a subroutine to back the operator up, in order for the operator to have a RakuAST operator node? 17:16
As long as it is an operator from the perspective of the user, I don't think it should
and actually, syntax sugar operators like the postcircumfix < > are added to RakuAST as operators 17:17
lizmat hmmm. maybe it *is* time to look at gist.github.com/lizmat/787a6ddb31d...f3403de78c again :-) 17:19
ab5tract nemokosch: Luckily it's not technically necessary if I replace the QAST calls, I just don't get any plug and play. So it appears that the answer is to have a Feed which subclasses Infix, but replaces the necessary parts. 17:28
nemokosch yes, that may be better 17:29
either way, this is just another example of what I'm worried about with RakuAST: without actually sitting down and thinking about what should be the nodes, it can very easily end up as a mixture of high-level Raku and internal behavior exposed 17:31
ab5tract A user presumably would not encounter this issue because they would have declared their infix somewhere in the lexical scope 17:33
but yes, I agree in principle with what you are saying 17:34
nemokosch Here I mean "user" as in somebody who might construct RakuAST for code generation 17:36
lizmat in that light: I think the checks for appropriateness of infixes in meta-operators, needs to move to the RakuAST classes, and *not* be handled by the grammar 18:11
Geth rakudo/main: 51b0afc4b8 | (Elizabeth Mattijsen)++ | src/Raku/ast/expressions.rakumod
RakuAST: group code a bit more logically

Also add some visual dividers		 18:55
ab5tract got Feed operators working : 20:25
though it was mostly copy-paste
ab5tract I wouldn't have worked out all that QAST on my own 20:38
leont lizmat: yeah, I really hope that will make it easier to set the iffiness/diffiness/fiddliness of a custom operator 20:46
Geth rakudo: ab5tract++ created pull request #5374:
RakuAST: Add ==> and <== feed operators		 20:50

Powered by Cro and the Raku® Programming Language.

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

Thank you!