🦋 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:01 reportable6 joined 00:26 japhb left 00:27 japhb joined
Geth rakudo: MasterDuke17++ created pull request #5241:
Copy stuff to RakuAST grammar that uses `.obs`		 01:25
01:50 japhb left 01:53 japhb joined
tbrowder__ tonyo: looking good, fez-guy! gonna add all functionality of App::Mii6 02:23
02:57 squashable6 left 02:59 squashable6 joined 04:56 bisectable6 left, reportable6 left, evalable6 left, bloatable6 left, linkable6 left, shareable6 left, releasable6 left, sourceable6 left, unicodable6 left, quotable6 left, nativecallable6 left, tellable6 left, benchable6 left, squashable6 left, coverable6 left, committable6 left, greppable6 left, notable6 left, statisfiable6 left, benchable6 joined, unicodable6 joined 04:57 tellable6 joined, quotable6 joined, greppable6 joined 04:58 reportable6 joined, bloatable6 joined, sourceable6 joined, bisectable6 joined, linkable6 joined, shareable6 joined, committable6 joined, statisfiable6 joined, evalable6 joined, notable6 joined 04:59 releasable6 joined, coverable6 joined, nativecallable6 joined, squashable6 joined 06:00 reportable6 left 06:01 reportable6 joined
Geth rakudo/main: b340c2b185 | MasterDuke17++ (committed using GitHub Web editor) | src/Raku/Grammar.nqp
Copy stuff to RakuAST grammar that uses `.obs`

These are directly copied from src/Perl6/Grammar.nqp and are primarily simple cases that just exist to give helpful error messages.		 07:28
08:01 sena_kun joined
lizmat I see that the V<> formatting code doesn't actually wind up in a FormattingCode object, which feels... wrong? 09:02
I mean, if you want stuff to be used verbatim, maybe you'd want it to be given a special style, rather than just be treated as ordinary content ? 09:03
well, I guess the documentation gives the answer: docs.raku.org/language/pod.html#Verbatim_text 09:04
hmmm
Nemokosch > only changes the way its contents are parsed, not the way they are rendered this doesn't even make sense 09:11
Is this trying to say that V<> doesn't erase the context it appears in? 09:15
lizmat it doesn't parse its contents for formatting codes, is what it does
Nemokosch Yes, so far so good. But obviously by changing the parsing, you DO change the rendering. The rendering is based on the parsing 09:17
It's the sentence that makes no sense, not the concept
lizmat ah, then make a documentation PR :-) 09:18
Nemokosch First I'd like to know what you deduced from this text 09:19
lizmat nine: maybe a strange idea, but regarding the parsing of pod for formatting codes, perhaps we should do that in Raku ? 09:20
I don't think we have pod in the setting, so we could do that in a module in core, which could be handy to have as a separate thing altogether ? 09:21
so that the Raku Grammar would just pass whatever is between the (conceptual) =begin / =end to a routine that would do the parsing ? 09:22
and that routine would live in core.c
do we have a reason why E<> formatting codes aren't directly rendered to graphemes ? 09:35
nine lizmat: oh I'm usually all for doing things in Raku. The caveat being that as I mentioned my POD knowledge is barely above 0, so I really can't say whether there would be any drawbacks or whether any of this would need to be more integrated into the Raku parser (e.g. for slangs, pragmas or the like) 10:26
lizmat well, it would be the part between =begin foo / =end foo 10:27
with any config already parsed
which you could consider to be a slang already
it would use the same trick as deparsing: a hllsym containing the class to do the parsing 10:28
m: $=pod.push("foo"); dd $=pod # this feels meh 11:51
camelia ["foo"]
12:00 reportable6 left
Nemokosch lol 12:00
12:01 reportable6 joined 14:27 vrurg left 14:38 nine left 14:40 vrurg joined 14:43 camelia left 14:49 camelia joined 15:08 camelia left 15:15 camelia joined 15:18 nine joined
lizmat nine: do we have a way to indicate that a RakuAST::Node does *not* produce any QAST ? 15:48
nine Not that I'm aware of 15:51
lizmat so returning an nqp::null is the closest to it I guess ? 15:56
tonyo tbrowder__: thanks dude
nine I guess you mean QAST::Op.new(:op<null>) 16:14
lizmat yup
[Coke] ...ok, but then it *is* producing QAST, no? :) 16:28
nine Well the whole machinery assumes that QAST is produced, so that is at least QAST with negigible effect. It's not pretty, but it's also low hanging fruit for when everything is finally working and we're looking for opportunities to optimize things. 17:10
lizmat so the way I see it atm, is that pod generates a RakuAST tree of objects, which then gets inserted in the current statement list as a Statement::Pod object 17:16
when the entire RakuAST of a compunit is QASTed, the QAST of the pod is generated into the $!pod-blocks array of the Compilation Unit, pushed one by one as they get to be QASTed 17:18
but the RakuAST pod tree itself would not produce anything (except maybe an nqp::null)
this would allow macros to add pod if they wanted to, specifically Declarator opd 17:19
*pod
18:00 reportable6 left 18:03 reportable6 joined 21:38 squashable6 left 21:39 sena_kun left 21:41 squashable6 joined 23:26 evalable6 left, linkable6 left 23:27 linkable6 joined 23:29 evalable6 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!