🦋 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.
raiph Per my simplified comment in github.com/rakudo/rakudo/issues/37...636248480: 02:03
I've golfed the issue to this, which has matched since 2014.01 at least:
r: say 'a' ~~ rule { .* a } 02:04
camelia Can't open perl script "/home/camelia/rakudo-j-inst/bin/eval-client.pl": No such file or directory
「a」
raiph As far as I can tell, in Rakudo, a significant space causes two alterations to a pattern: 02:05
1. Inserts a <ws>.
2. Switches (greedy) backtracking on for the preceding atom.
I think we need to decide if I'm right (or at least if it's something like what I describe) and if so, what to do about it. 02:06
I think a first step that would be helpful would be anyone doing either or both of the following: 02:08
1. Find a counter example. (I've tried and failed to do so.) 02:09
2. Make sense of the Rakudo code handling `:sigspace`. (I've tried and failed to do so.) 02:10
japhb rules ratchet, they don't backtrack
raiph That's what I thought for a decade.
Actually, of Raku as against Rakudo, more like nearly two decades. 02:11
japhb: Which is why this is a bit of a stunner. 02:12
`rule`s do turn on `:r`. 02:13
But in Rakudo significant spaces insert what I'll simplify as `!<ws>`, not merely `<ws>`.
Thus these are equivalent: 02:14
m: say 'a' ~~ regex { .* . }
camelia 「a」
raiph m: say 'a' ~~ rule { .*!. } 02:15
camelia 「a」
raiph say 'a' ~~ rule { .* . } 02:16
evalable6 「a」
japhb say 'a' ~~ rule { a* a } 02:17
evalable6 「a」
japhb Wish I could just invoke moritz at this point ... 02:19
raiph I realize I misspoke when I wrote the above are equivalent.
m: say 'a' ~~ regex { .* . }
camelia 「a」
raiph is of course the same as:
m: say 'a' ~~ rule { .*!<ws>.<ws>} 02:20
camelia 「a」
ws => 「」
ws => 「」
raiph Er, shoot:
m: say 'a' ~~ rule { .*!<.ws>.<.ws>}
camelia 「a」
raiph (No ! on the second atom because it's not quantified so no need / wouldn't be valid syntax) 02:21
But yeah, it really is amazing, but we need to face it down.
Damn. I've gotten the equivalence wrong *again*. 02:22
I'm tired.
But I have checked this out when not tired.
It'
Gah!
It's been 3 years since I was first shocked by this. 02:23
It's 3am. I need to go to sleep. But please don't dismiss this. 02:24
jnthn agreed something was wrong. but we never pursued it. 02:25
japhb wonders if this is why our compiles are slow ... 02:26
raiph Yes, I spent 3 years thinking about Larry's 2017 comments about the need to port STD's fates to Rakudo. 02:28
And then the next 3 years thinking about this bit too.
(Well, mulling them from time to time, then trying to research code etc, then not getting back to raising these issues.) 02:30
They're independent issues. But in combination they presumably amount to something like at least a 10X cost. 02:32
(10x in the sense that the code processing each character gets run on average 10X as much as it needs to be run.) 02:34
(Larry estimated that the fates system he prototyped in STD and began to port to Rakudo would save something like 5 to 6 times.) 02:35
(I wonder if the reason he got depressed was no matter how hard he tried, his port of his fates system insisted on backtracking...) 02:37
Maybe I misunderstand all that kind of stuff. 02:39
The bit I know is wrong is that rules are switching backtracking on for quantified atoms followed by a significant space. 02:40
As far as I can tell it's ALL such atoms.
Goodnight.
raiph Darn, forgot to say the most important thing. 02:43
This ultimately isn't about speed, even though that would be nice. 02:44
It's about the (non) matching impact if for 6.e we make significant spaces only insert `<ws>` and *not* make preceding atoms backtrack. 02:47
patrickb jdv: The precompiled release archives are now also uploaded. 07:54
Geth Slang-Roman/main: 7ce3abb7a2 | (Elizabeth Mattijsen)++ | 3 files
0.5
09:17
lizmat nine ab5tract do we have the equivalent of a bare WVal in RakuAST? 09:22
ab5tract not that I've encountered 09:26
ab5tract lizmat: one more spectest down :D 10:34
m: Q| sub infix:<quack>($x,$y) { "$x|$y" }; dd ((* quack *) quack (* quack (* quack *))).(2, 3, 5, 6, 7) | .AST.EVAL 10:35
camelia ===SORRY!=== Error while compiling <tmp>
Two terms in a row
at <tmp>:1
------> Q| sub infix:<quack>($x,$y) { "$x|⏏$y" }; dd ((* quack *) quack (* quack (*
expecting any of:
infix
infix stopper
s…
lizmat whee!
ab5tract weird, I never saw that error before... 10:36
anyway, nested whatever-curried infixes are fixed. that was a bit of a mind bender, but it also helped me cleanup the ApplyPostfix code a lot 10:37
lizmat hehe... so that PR is ready now?
ab5tract yup :)
lizmat kewl
5385 right ?
ab5tract precis
lizmat squash or not ? 10:38
ab5tract prefer not, since they are pretty different fixes
lizmat okidoki
ab5tract s/different/distinct/
lizmat hmmm.. never saw this option before: rebase and merge... that looks like the one you want, right ? 10:40
ab5tract I believe so, yeah
Geth rakudo/main: 0307ea9aae | ab5tract++ (committed by Elizabeth Mattijsen) | src/Raku/ast/expressions.rakumod
RakuAST: Fix topic over-simplification in curried ApplyPostfix

Fixes code like the following:
  ```
  $_ = 42; (Int).map: *.new: $_
  ```
... (6 more lines)
10:41
rakudo/main: dfaa8c2895 | ab5tract++ (committed by Elizabeth Mattijsen) | src/Raku/ast/expressions.rakumod
RakuAST: Fix nested infix WhateverCodes

This enables the following:
  ```
sub infix:<quack>($x,$y) { "$x|$y" }; say ((* quack *) quack (* quack (* quack *))).(2, 3, 4, 5, 6)
  ```
ab5tract part of me wants to keep hammering away at * until I can get S02-types/whatever.t passing 10:49
but another part of me fears that in this way lays madness 10:50
what's neat about these * patches is that the QAST they generate is quite distinct from what the old compiler does 10:51
but it still works fine :)
maybe "quite distinct" is an overstatement, but distinct nonetheless 10:52
ab5tract btw lizmat I didn't see your comment on github.com/rakudo/rakudo/pull/5373 10:58
it is ready :) 10:59
Geth rakudo/main: a6ec8dfe49 | ab5tract++ (committed by Elizabeth Mattijsen) | src/Raku/ast/type.rakumod
RakuAST: Treat QuotedString with literal elements as compile-time
rakudo/main: 05ba0ef082 | ab5tract++ (committed by Elizabeth Mattijsen) | src/Raku/Grammar.nqp
RakuAST: Make parameterized roles with lexicals compile
lizmat 954 +1 :-) 11:06
ab5tract don't forget to close github.com/rakudo/rakudo/issues/5343 11:10
lizmat done, thanks for the nudge 11:14
Geth rakudo/main: 89755eb02f | (Elizabeth Mattijsen)++ | 2 files
RakuAST: Introduce RakuAST::Constant base class

This class intended to be used by slangs / macros that want to codegen a constant value *and* be in control of how the value deparses. For instance for Slang::Roman:
   class RakuAST::RomanLiteral is RakuAST::Constant {
... (6 more lines)
11:47
lizmat afk for a few hours& 11:48
Geth File-Find/main: ec6ebba449 | (Tom Browder)++ | 5 files
Convert to three separate os workflows and badges
13:16
File-Find/main: ef35046417 | (Márton Polgár)++ (committed using GitHub Web editor) | .github/workflows/windows-spec.yml
don't hardcode the files to test on windows either

Following ugexe's suggestions from earlier and doing some research of zef.
File-Find/main: fb1adf6609 | (Márton Polgár)++ (committed using GitHub Web editor) | 5 files
Merge pull request #44 from tbrowder/3os

Convert to three separate os workflows and badges
[Coke] good day, folks. 13:41
jdv patrickb: cool 14:05
Geth Slang-Roman/main: 55287c7efe | (Elizabeth Mattijsen)++ | lib/Slang/Roman.rakumod
Use new RakuAST::Constant class

This should probably wait for release until 2023.10
14:46
Slang-Roman/main: ec65d26445 | (Elizabeth Mattijsen)++ | lib/Slang/Roman.rakumod
Revert "Use new RakuAST::Constant class"

This reverts commit 55287c7efe4d2c40fb6e2c967ff50a86edfe64f5.
Waaaaayyy too soon! Fixes CI
14:50
rakudo: ab5tract++ created pull request #5389:
CircleCI Commit
15:53
ab5tract that was a mistake 15:56
ab5tract m: Q| * * * + * | .AST.say 17:13
camelia RakuAST::StatementList.new(
RakuAST::Statement::Expression.new(
expression => RakuAST::ApplyInfix.new(
left => RakuAST::ApplyInfix.new(
left => RakuAST::Var::Lexical.new("*"),
infix => RakuAST::Infix.new("*"),…
Geth rakudo/lizmat-otherwise: 5650b70105 | (Elizabeth Mattijsen)++ | 3 files
RakuAST: implement for { } otherwise { }

I was looking at what would need to be done to port the Slang::Otherwise module to work with RakuAST, and realized it was probably less work to just implement the functionality in the Raku grammar.
This does: ... (12 more lines)
18:22
rakudo: lizmat++ created pull request #5390:
RakuAST: implement `for { } otherwise { }`
18:23
nemokosch to introduce language syntax in a mere PR? 21:01
possibly even retrospectively? 21:02
lizmat that's why I put it in a PR 21:44
nemokosch It seems like a rather defective workflow, but more on that in the comment 21:52