|
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. |
|||
|
07:17
ilbot3 joined
|
|||
| masak | heh. I've got an unhygienic declaration (#88) working locally, but with a lot of test suite fallout. | 08:21 | |
| vendethiel- | cool :D. | 08:25 | |
| that's pretty nice | |||
| masak | the conceptual difficulty I'm bumping up against now is definitely one I've been avoiding for a while: the fact that macro calls are *expressions*, but they may introduce, depending on the Qtree returned, either expressions, statements, or statement lists | 08:36 | |
| actually, even that is a bit too narrow | 08:37 | ||
| a macro could return a Q::Trait, and there'd be no way to evaluate that in an ordinary expression, because it has neither a value or a statement-like behavior | |||
| I'm taking a keyboard break to brood and mull over this | 08:38 | ||
| ok, I've done some thinking | 13:17 | ||
| result's still pretty fresh, so I may not be good at explaining it, but here goes: | |||
| there are three major categories of Q node types -- everything belonging to the expression language (Q::Expr), everything belonging to the statement language (Q::Statement), and then various other minor things like traits | 13:18 | ||
| it's not *wrong* a priori to try to inject a trait using a macro, but the only place it'll ever have any chance of succeeding is inside an unquote: {{{ trait_producing_macro() }}} | 13:20 | ||
| or maybe even {{{ trait_producing_macro() @ Q::Trait }}} | 13:28 | ||
| which means we're back to the original question from github.com/masak/007/issues/7 -- what about the (very common) situation where a Q::StatementList gets injected into an expression? | 13:29 | ||
| we don't get much help from the "What Would LISP Do?" line of inquiry, because LISP considers everything to be an expression, and we don't. I don't think that's just language designer stubbornness on my part; Perl 6 doesn't consider everything to be an expression either. | 13:31 | ||
| reading through #7, I don't think we need the ⦃...⦄ solution anymore. contextualized identifiers get us that result for free. | 13:33 | ||
| the only thing we need to solve is the fact that a statementlist peg doesn't fit snugly in an expression slot. | |||
| so maybe the macro application code makes it fit by putting a Q::Expr::StatementListAdapter there, or something | 13:34 | ||
| besides making sure the Q hierarchy remains sane, this Q type also makes sure to extract the value of the last statement from the statement list, returning it as the result of the .eval() | 13:35 | ||
| vendethiel- reads up | 14:26 | ||
| masak | also, I'm not a big fan of the name Q::Expr::StatementListAdapter, but it does get points for clarity | 14:48 | |
| vendethiel- nods | 14:49 | ||
| masak | oh, actually the fallout doesn't look so bad. I might be able to fix this easily. | 15:02 | |
| vendethiel- | basically (-> {})(), anyway | 15:04 | |
| masak | kinda, yes | 15:09 | |
| except we killed off expression blocks in 007, brought them back to life as expression subs, and at no point did the last statement return a value out of its block without a `return` statement | 15:10 | ||
| but that's just minor details | |||
| heh, down to one unexpected test failure in t/integration/corner-cases.t :D | |||
| I love that test file | |||
| oh dang, one of those | 15:12 | ||
| test succeeds when I run it in isolation with bin/007 | 15:13 | ||
| it fails consistently in its location in the test file | |||
| it succeeds when I remove all tests prior to it | |||
| actually, it seems to succeed when I remove *any* of the 20 tests prior to it | 15:15 | ||
| masak quarantines is | |||
| it* | |||
| vendethiel- | Oo | 15:17 | |
| masak | ok, besides this being a bit to sort out at commit-time, it wasn't all that bad | 15:25 | |
|
16:34
Ven joined
17:17
FROGGS joined
17:32
Ven joined
|
|||