Perl 6 - the future is here, just unevenly distributed

IRC log for #6macros, 2016-02-07

| Channels | #6macros index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
07:17 ilbot3 joined #6macros
08:21 masak heh. I've got an unhygienic declaration (#88) working locally, but with a lot of test suite fallout.
08:25 vendethiel- cool :D.
08:25 vendethiel- that's pretty nice
08:36 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:37 masak actually, even that is a bit too narrow
08:37 masak 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
08:38 masak I'm taking a keyboard break to brood and mull over this
13:17 masak ok, I've done some thinking
13:17 masak result's still pretty fresh, so I may not be good at explaining it, but here goes:
13:18 masak 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:20 masak 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:28 masak or maybe even {{{ trait_producing_macro() @ Q::Trait }}}
13:29 masak which means we're back to the original question from https://github.com/masak/007/issues/7 -- what about the (very common) situation where a Q::StatementList gets injected into an expression?
13:31 masak 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:33 masak reading through #7, I don't think we need the ⦃...⦄ solution anymore. contextualized identifiers get us that result for free.
13:33 masak the only thing we need to solve is the fact that a statementlist peg doesn't fit snugly in an expression slot.
13:34 masak so maybe the macro application code makes it fit by putting a Q::Expr::StatementListAdapter there, or something
13:35 masak 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()
14:26 * vendethiel- reads up
14:48 masak also, I'm not a big fan of the name Q::Expr::StatementListAdapter, but it does get points for clarity
14:49 * vendethiel- nods
15:02 masak oh, actually the fallout doesn't look so bad. I might be able to fix this easily.
15:04 vendethiel- basically (-> {})(), anyway
15:09 masak kinda, yes
15:10 masak 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 masak but that's just minor details
15:10 masak heh, down to one unexpected test failure in t/integration/corner-cases.t :D
15:10 masak I love that test file
15:12 masak oh dang, one of those
15:13 masak test succeeds when I run it in isolation with bin/007
15:13 masak it fails consistently in its location in the test file
15:13 masak it succeeds when I remove all tests prior to it
15:15 masak actually, it seems to succeed when I remove *any* of the 20 tests prior to it
15:15 * masak quarantines is
15:15 masak it*
15:17 vendethiel- Oo
15:25 masak ok, besides this being a bit to sort out at commit-time, it wasn't all that bad
16:34 Ven joined #6macros
17:17 FROGGS joined #6macros
17:32 Ven joined #6macros

| Channels | #6macros index | Today | | Search | Google Search | Plain-Text | summary