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.
03:06 vendethiel joined 06:06 cgfbee joined 06:07 cgfbee joined 07:27 FROGGS joined 09:57 masak_ joined 13:50 Ven joined 14:32 Ven_ joined
masak I think I was wrong about irclog.perlgeek.de/6macros/2015-12-20#i_11749311 yesterday 15:30
in fact, parsing it and producing a Q::Quasi with a Q::Unquote in it isn't the problem
that already falls out of everything
the problem is that when we then evaluate that Q::Quasi, it will want to completely interpolate all Q::Unquote nodes it finds 15:31
still, I think it actually *would* be useful to create an unquote node non-synthetically sometimes, at least in higher order macro programming 15:33
so I'm thinking we might want to make `my unquote = quasi @ Q::Unquote { {{{whatevs}}} };` evaluate to an unquote through some kind of exception (to the rule "in quasi evaluation, all unquotes go away")
I have two possible ways to implement this, and I haven't decided which way I like better: 15:34
① manually flag up the Q::Quasi created by `quasi @ Q::Unquote` with a special flag meaning "don't interpolate the unquote(s) in this quasi tree" 15:36
② never interpolate a quasi with only a single unquote in it 15:37
16:04 andreoss joined
masak o/ 16:08
Ven_ \\o andreoss
I'm not sure what you mean by 2), masak 16:09
masak andreoss: thank you for your contributions recently.
Ven_ breaking "eta-expansion" that mandates "a" is "quasi { {{{a}}} }" for all unquote a?
masak yeah, something like that
Ven_ -1 then 16:10
I don't see any reason to break people's expectations, that'd only be an edge case
masak right 16:11
① it is, then
Ven_ I didn't reply earlier because I'm not sure OTTOMH what that should be
I guess I'd need to write up an example of a macro-generating macro and start to think about it.
masak *nod* 16:12
me too :)
I wonder if we'll want to make rhs of the `@` in an unquote unquotable :) 16:14
ditto the one in a quasi 16:16
Ven_ yes, we need that for nested macros
masak oki 16:18
should be fine 16:19
just didn't consider it before...
{{{x @ {{{qtype}}} }}} # :) 16:20
andreoss masak: should lexical closures be working for now? 16:37
ok, it works 16:39
Ven_ looks pretty bad D: 16:43
but it's very good if it works
masak lexical closures have been working for something like year ;) 16:45
andreoss: by the way, have you found ROADMAP.md yet? 16:46
Ven_ first draft gist.github.com/vendethiel/cdc4167f6492f2f62bf2 16:49
andreoss masak: i did skim thought it
i find your blog entry quite more informative though
also examples/ were hidden under separate branch, but i found it anyway 16:52
masak heh :) 17:10
examples/ is a work in project
but yes, seems you've done your homework
Ven_: cool! 17:11
andreoss some X::TypeCheck constructed with a message passed as :expected() argument. Is it on purpose? When this exception stringifies only a type of that parameter is used 17:34
> die X::TypeCheck.new(:operation<int()>, :got($_), :expected("something that can be converted to an int"));
this will throw `expected Str but got ...`, was it intended? 17:35
18:20 vendethiel joined
andreoss masak: i wonder if it's possible to add some call-to-host function in 007. And instead of polluting code with operators, move all of them to a some kind of standard library, where they will be defined via call to Perl6 18:36
sub infix:<+>(a, b) { return (call_host("_007::Builtins::addition({a}, {b})")) }; 18:38
or even
sub infix:<+>(a,b) { return(call_host("{a} + {b}")) } 18:46
19:11 FROGGS joined 19:18 FROGGS joined
masak andreoss: no, not intended 19:30
andreoss: I've discovered some like that too now and then. we're a little bit bad at testing exception messages 19:31