|
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 28 July 2015. |
|||
|
02:56
ilbot3 joined
12:26
Ven joined
14:45
Ven joined
16:42
Ven joined
|
|||
| Guest48681 | I'm re-reading the macros discussion to giv myself a bit of context | 17:20 | |
| Ven`` | We're still missing calls(maybe variables) and captures | 17:21 | |
| Those are the two big regex things we're missing and once we get that we should be able to look further into the future | 17:22 | ||
| I was thinking about captures mostly about the is parsed ticket, or more specifically, the ?? !! ticket | |||
| macro infix:<?? !!>(condition: Q::Expr, then_part: Q::Expr, else_part: Q::Expr) | 17:24 | ||
| is parsed(/"??" <EXPR> "!!"/) | |||
| how does that work? | |||
| the point #3 about capturing is also very interesting | 17:25 | ||
| well -- the whole issue text makes it feel like is parsed deals with parsing **the operator** | 17:26 | ||
| the category is already determined, and while trying to parse operators it tries this one | 17:30 | ||
| while "shutter-yarding", it uses ?? !! as the "canonical name" | |||
| masak | yeah, there are many open questions in that space | 20:02 | |
| for example, should we make it a compile-time error if the first word in the op name differs from the first term in the regex? (probably) | 20:03 | ||
| should we also make it an error for subsequent words not to match some part of the rest of the regex? (don't think so) | |||
| I'm not 100% pleased with the "positional binding" approach -- but I believe it might get us off the ground and maybe better able to aim for the next local maximum | 20:05 | ||