6macros: discussing the finer points of Perl 6 macros, Qtrees, and how to stay sane | irclog: irclog.perlgeek.de/6macros/today
Set by moderator on 17 July 2015.
06:46 vendethiel joined 07:36 vendethiel joined 08:29 vendethiel joined
masak re-reads strangelyconsistent.org/blog/macros...long-break and is filled with the enthusiasm of the original vision 10:20
as to parsing, I think we should be asking "what's the simplest thing that could possibly work?" and then do that for starters 10:26
maybe explicitly considering it a first prototype
having access to the grammar's own rules seems essential to doing this in a good way
there's no way I'll go and re-implement <variable>, have you seen that thing? 10:27
or <EXPR>, for that matter.
and thinking ahead with slangs, it's not really Perl6::Grammar that we should be given access to, it's $~MAIN 10:28
vendethiel [12:26] <masak> there's no way I'll go and re-implement <variable>, have you seen that thing?
[12:27] <masak> or <EXPR>, for that matter.
you mean, in v5?
or rather, in our own grammar 10:29
masak let's assume for the purpose of that question that we accepted `is parsed` wholesale
then I should be able to write `<variable>` inside the `is parsed` regex, and it should resolve.
vendethiel well, a big different between how I see macros and how you see macros is that 10:30
you "believe" in "is inside(&other-macro)"
whereas I believe more in codewalkers
masak I think that's a difference we can very well overcome. 10:37
I definitely believe in codewalkers, too.
but keep in mind that, at least absent parsing shenanigans, if you pass a block to a macro, that block has to be already parsed.
that's just the way Perl 6 rolls. 10:38
vendethiel yep, but that's a pretty issue
as in, mixing levels like that makes it much harder everywhere.
and it's not like there's another solution 10:39
masak re-read strangelyconsistent.org/blog/macros...s-in-a-row 10:40
"The Perl 6 chorus today sings about *grammars*, and sometimes action methods. But the `is parsed` trait still mumbles about its regexes, making itself a bit of an embarrassment, to be honest. It hasn't gotten the memo that all the rest of us are doing structured language parsing, not just text munging." 10:41
I'm mulling about this one today.
I realized that not having action methods in a macro is not such a show-stopper after all.
vendethiel well, the macro itself is 10:42
masak but what we do want is something like a simple way to cast `Q::Var($<variable>)`
so you can really easily get the Qtrees out of your parsed elements.
vendethiel yeah, but... 10:43
all the code I wrote had some variable shenanigans
masak interestingly, something like <xblock> doesn't have a Qtree. you have to unpack it yourself. that's fair, I guess.
yes, the variable shenanigans are *very important* to get right, I agree. 10:44
I think if we sat down and thought hard-ish about it, we could reduce it to five or so orthogonal use cases that simply have to work.
maybe that's a good thing to do at Swiss
vendethiel also, more brains! :P 10:45
masak braaaaaaaains
vendethiel still needs to finish his talk, but got a better angle now
masak that blog post hypothesizes that the action methods of the original grammar will still run as usual. 10:46
I'm not 100% sure that's a good idea, but... I think it could work out. 10:47
that'd just mean that the Qtrees are already there, in the $/.ast attributes
ah, you said I believe in `is inside` because of this post: strangelyconsistent.org/blog/macros...ing-macros 10:49
I'm not married to that solution. 10:50
vendethiel yes, I did
also, I'd like to see a gist example of what you're talking about here :) 10:52
masak me too :)
"the most generic macro in P6 is going to look a lot like a parsing rule with an AST maker for its action closure, which may or may not build the returned AST out of quasis, that may or may not refer to the bits parsed by the parse rule, presumably by the same name they were parsed under" 10:55
I like that sentiment (by TimToady)
13:26 vendethiel joined 15:41 Ven joined