|
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:51
FROGGS joined
03:25
FROGGS joined
03:46
FROGGS joined
04:12
FROGGS joined
08:49
FROGGS joined
09:13
FROGGS joined
|
|||
| masak | g'ah -- the first real thing I want to do with someObj.update is to send in a single property whose key is unknown at compile time... | 11:03 | |
| I bet this could be solved with a macro, though... | |||
| masak hurries up and implements flexible enough unquotes | 11:10 | ||
|
13:42
FROGGS joined
14:12
ilbot3 joined
14:28
ilbot3 joined
15:23
pdcawley joined
16:34
FROGGS joined
18:27
pdcawley joined
18:57
FROGGS joined
|
|||
| masak | TIL: when you do a `quasi @ Q::Term`, what you get back may legitimately be a Q::Infix::Addition. guess how? :) | 20:02 | |
|
21:29
vendethiel joined
|
|||
| masak | ok, moment of truth | 21:43 | |
| I just started implementing this, and ran right into the central question | |||
| what kind of Qtree does `quasi { 2 {{{op @ Q::Infix}}} 2 }` give back? | |||
| that unquote there is in effect some kind of "infix unquote" | 21:44 | ||
| we could make a Q::Unquote::Infix with a $.lhs and a $.rhs, that could work | |||
| ditto Q::Unquote::Prefix and Q::Unquote::Postfix | 21:45 | ||
| I wonder if we'll end up needing more specialized unquote types than that -- I think not. this is 'cus of the strange non-nesting behavior of operators, which is unique | 21:46 | ||
| vendethiel | mmmh... | 21:47 | |
| idk | |||
| masak | and then we make even *considering* comparing the precedence/associativity of an operator unquote with something else a fatal parsing error, at least until we figure out how to do that sanely | ||
| vendethiel: before I fell asleep last night, I had a nightmarish vision: `quasi < quasi [ <<<foo @ [[[bar]]]>>> ] >` | 21:49 | ||
| vendethiel | please no :P | ||
| masak | not sure how I managed to sleep after that | ||
| how would it even... I... what... | 21:50 | ||
| though now that I think about it with the benefit of "daylight", I think that it's a kind of parse error | 21:51 | ||
| because the `[[[bar]]]` part happens in a <<<>>>-style unquote environment, which is very much like the *outside* of the outer quasi, and therefore simply doesn't recognize the [[[]]] things | 21:52 | ||
| (it *would* recognize a `<<<bar>>>` thing, by the grace of the `<<<...>>>` unquote still being a modified environment) | 21:53 | ||
| g'ah, this stuff literally equals brain damage | 21:54 | ||
| vendethiel | XD | ||
| I think it's far easier to reason about this in lisp, for now | 22:07 | ||
| ie, especially the nested unquote stuff | 22:08 | ||
| ``(,,a) | |||
| masak | we're already diverging from that | 22:11 | |
| in the `{{{ op @ {{{type @ Q::Identifier}}} }}}` syntax, for example, the two {{{ }}} unquotes bind to the same quasi | 22:12 | ||
|
22:26
vendethiel joined
|
|||
| masak | yay, 007 has comments now | 22:44 | |
| turns out the patch wasn't so hard after all | |||
| vendethiel | huh? | 22:47 | |
| they shouldn't | |||
| that's definitely not what I meant by this syntax, at least. | |||
| masak | oh, interesting | 22:48 | |
| that we meant different things | |||