🦋 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
02:11
evalable6 left,
tellable6 left,
bloatable6 left,
statisfiable6 left,
benchable6 left,
squashable6 left,
sourceable6 left,
shareable6 left,
bisectable6 left,
releasable6 left,
unicodable6 left,
committable6 left,
quotable6 left,
nativecallable6 left,
reportable6 left,
linkable6 left,
notable6 left,
greppable6 left,
coverable6 left,
quotable6 joined,
nativecallable6 joined,
sourceable6 joined,
linkable6 joined,
notable6 joined
02:12
tellable6 joined,
shareable6 joined,
committable6 joined,
reportable6 joined
02:13
greppable6 joined,
squashable6 joined,
bisectable6 joined,
statisfiable6 joined,
coverable6 joined,
bloatable6 joined
02:14
benchable6 joined,
evalable6 joined,
releasable6 joined,
unicodable6 joined
02:25
MasterDuke left
02:38
codesections left
03:31
Xliff left
05:05
coverable6 left,
releasable6 left,
benchable6 left,
evalable6 left,
quotable6 left,
bisectable6 left,
shareable6 left,
sourceable6 left,
greppable6 left,
unicodable6 left,
linkable6 left,
reportable6 left,
notable6 left,
committable6 left,
tellable6 left,
bloatable6 left,
squashable6 left,
statisfiable6 left,
nativecallable6 left,
sourceable6 joined,
nativecallable6 joined
05:06
benchable6 joined,
quotable6 joined,
coverable6 joined,
notable6 joined
05:07
releasable6 joined,
bisectable6 joined,
greppable6 joined,
committable6 joined,
unicodable6 joined,
squashable6 joined,
evalable6 joined,
statisfiable6 joined,
shareable6 joined
05:08
linkable6 joined,
reportable6 joined,
bloatable6 joined,
tellable6 joined
06:00
reportable6 left
06:02
reportable6 joined
09:04
discord-raku-bot left
09:05
discord-raku-bot joined
09:41
ab5tract joined
10:02
[Tux] left
|
|||||||||||||||||||||||||||||||||||||||
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 | |||||||||||||||||||||||||||||||||||||||
10:13
[Tux] joined
|
|||||||||||||||||||||||||||||||||||||||
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] |
|
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 | |||||||||||||||||||||||||||||||||||||||
11:13
linkable6 left,
evalable6 left
11:14
linkable6 joined,
evalable6 joined
|
|||||||||||||||||||||||||||||||||||||||
lizmat | ok, it looks like the grammar / actions are altering the body to get rule/token semantics | 11:16 | |||||||||||||||||||||||||||||||||||||
12:00
reportable6 left
12:03
reportable6 joined
|
|||||||||||||||||||||||||||||||||||||||
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 | |||||||||||||||||||||||||||||||||||||
13:03
linkable6 left,
evalable6 left
13:06
evalable6 joined,
linkable6 joined
|
|||||||||||||||||||||||||||||||||||||||
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 | |||||||||||||||||||||||||||||||||||||
17:02
linkable6 left,
evalable6 left
17:03
linkable6 joined
17:04
evalable6 joined
17:18
codesections joined
18:00
reportable6 left
18:01
reportable6 joined
22:51
japhb left,
japhb joined
22:52
ugexe left
23:01
ugexe joined
|