🦋 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.
Geth rakudo: MasterDuke17++ created pull request #5241:
Copy stuff to RakuAST grammar that uses `.obs`		 01:25
tbrowder__ tonyo: looking good, fez-guy! gonna add all functionality of App::Mii6 02:23
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
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"]
Nemokosch lol 12:00
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

Powered by Cro and the Raku® Programming Language.

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

Thank you!