🦋 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.
00:00 reportable6 left 00:02 reportable6 joined
nemokosch It seems legit that the result is a List 00:05
01:03 dogbert17 left 01:06 dogbert17 joined 03:25 linkable6 left, evalable6 left 03:27 evalable6 joined, linkable6 joined 05:14 reportable6 left, linkable6 left, coverable6 left, nativecallable6 left, tellable6 left, quotable6 left, benchable6 left, evalable6 left, bisectable6 left, unicodable6 left, sourceable6 left, greppable6 left, statisfiable6 left, shareable6 left, notable6 left, squashable6 left, committable6 left, sourceable6 joined, quotable6 joined 05:15 tellable6 joined, squashable6 joined, linkable6 joined, committable6 joined, nativecallable6 joined, shareable6 joined, evalable6 joined, bisectable6 joined 05:16 reportable6 joined, coverable6 joined, benchable6 joined, statisfiable6 joined, unicodable6 joined 05:17 notable6 joined, greppable6 joined 06:00 reportable6 left 06:44 ab5tract joined
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
11:47 reportable6 joined
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
12:00 reportable6 left 13:35 reportable6 joined
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
17:07 linkable6 left, evalable6 left 17:08 evalable6 joined 17:10 linkable6 joined
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
17:19 jgaz left
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
18:00 reportable6 left 18:01 reportable6 joined
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
18:39 guifa__ left
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
20:28 jgaz joined
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
22:47 Voldenet left 22:53 Voldenet joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!