🦋 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.
lizmat just realizes there is no syntax in Raku to create a nameless sub with traits and placeholder variables 10:12
yet it *is* possible to create one with RakuAST
Geth rakudo/main: f41c769d17 | (Elizabeth Mattijsen)++ | 7 files
RakuAST: use Signature.parameters-initialized as rendering check

And remove RakuAST::PlaceholderParameterOwner.code-has-placeholders logic. The latter suffered from the following situation:
   sub foo (@_) { @_ }
... (12 more lines)
10:22
rakudo/main: f72d58bcda | (Elizabeth Mattijsen)++ | t/12-rakuast/placeholder.rakutest
RakuAST: add fake slurpy array/hash tests
10:31
lizmat nine: could it be that regex / token / rule are all codegenned as RegexDeclaration without any difference ? 10:53
I don't see $*IN_DECL being passed into anything anywhere ? 10:54
nine lizmat: there must be some difference as otherwise they would all behave the same way 10:57
lizmat well... maybe that is a bug ?
ok, will investigate further
from what I can see, "my regex foo { a }", "my token foo { a }" and "my rule foo { a }" currently all create the same AST 11:00
I sorta expected something to happen inside the bodies, but no
nine Do they generate the same QAST? 11:01
lizmat checking now 11:02
looks like they're identica;l 11:03
yup, only the source references are different 11:05
[Tux] Rakudo v2022.12-1-gd52342eb0 (v6.d) on MoarVM 2023.02-3-g6adfc376c
csv-ip5xs0.798 - 0.823
csv-ip5xs-205.046 - 5.539
csv-parser3.552 - 3.709
csv-test-xs-200.411 - 0.516
test6.468 - 6.887
test-t1.358 - 1.439
test-t --race0.803 - 0.860
test-t-2020.818 - 21.056
test-t-20 --race6.220 - 7.181
11:06
lizmat oddly, the old QAST also looks identical 11:09
hmmm... the regex / token QAST looks the same, the token / rule QAST differs in old and new 11:11
looks like the rule has added a .ws to the QAST
lizmat ok, it looks like the grammar / actions are altering the body to get rule/token semantics 11:16
Geth rakudo/main: 9245f985e5 | (Elizabeth Mattijsen)++ | 4 files
RakuAST: first stab at deparsing/.raku of regex/token/rule

The main problem was that "regex" / "token" / "rule" all codegenned to RakuAST::RegexDeclaration, with (probably) tweaks applied to the body.
This commit introduces two subclasses of RakuAST::RegexDeclaration: ... (9 more lines)
12:20
Geth rakudo/main: 6a2fee72e6 | (Elizabeth Mattijsen)++ | src/core.c/RakuAST/Raku.pm6
RakuAST: some .raku tweaks / fixes
13:42
nine lizmat: isn't that missing some change in Actions? 14:09
lizmat no?
what gets passed is the name of the class to create 14:10
I changed that, and added some classes
nine But that means it doesn't matter whether I create a TokenDeclaration or RuleDeclaration, they will behave the same
lizmat yes, indeed, so there was no test breakage 14:11
but it allowed deparsing and .raku to do the right thing
apart from the actual body still showing alterations done
when it should hide them 14:12
I'm working on that now
nine In my view, that's now worse than before. Before it was clear, that a RegexDeclaration is a RegexDeclaration and any difference in behavior must come from its contents. Now I'd create a TokenDeclaration, expecting this to behave like a token, but it won't. 14:13
lizmat agree... so I'm working on that, so that you would *not* have to add WithSigspace to each node in the case of a rule 14:14
but that they would get added automagically at some point 14:15
nine Ah, so it is indeed incomplete and will be completed :) Then I won't keep you from doing that anymore
lizmat yeah, I got the whitespace location where that gets added 14:16
now I still cannot find the ratchet behaviour difference between regex and rule/token 14:17
nine: do we have something that can mangle ASTs already ? 14:51
or is it bespoke with a visit-children(&handler) ?
nine Don't think we have anything yet. So far we didn't have to manipulate much 15:19
lizmat ack 15:20