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.
01:20 vendethiel joined 01:41 cgfbee joined 06:28 FROGGS joined 07:31 Ven joined 07:42 Ven joined 07:47 Ven joined 09:26 Ven joined 10:07 Ven joined 11:43 Ven joined 13:19 Ven joined
masak FROGGS: hi. vendethiel invited you to this channel because the two of you had discussed macros, and it might be useful to share things here. 13:57
current status: I'm still learning about macros. I have a pretty good sense of what it is we want in Perl 6 at this point, but there is precious little in the form of mechanisms.
FROGGS and I have problems groking the scope of macros and/or slangs, and how they should play together in case they should play together at all 13:59
so, maybe it would help me if I had usecases mapped to (pseudo)code, so I can image how a problem might be solved eventually 14:00
the implementation is then just a matter of details me thinks
masak ok, so 14:01
Ven I should've be writing things down when you were talking
masak looking simply at popular demand, people want to build-auto+generate program fragments using macros
auto-generate*
the top three is probably (a) methods, (b) subs, (c) classes 14:02
but I've also seen people wanting to construct given/when statements using a macro
it would be good to have stories for those
FROGGS okay... 14:07
you know the one use case I provided...
masak yes 14:08
FROGGS say there is a sub declared foo_i64, and I want to have a macro call('i64') that will expand the subname
now this is just a string and seems simple 14:09
but if the call() surrounds a bigger code block, who parses it?
s/who/what/
because Perl 6 cant parse stuff like i64 and pretend it will expand to a subroutine name, it will blow up instead because we do one pass parsing 14:10
so my issue is that I don't know how the usage of macros will *look* like
to then abstract what it means implementation wise
masak I've been thinking about exactly that bit lately 14:11
there are two ends to it, so to speak
on the caller end, you're absolutely right -- writing it without the string quotes is problematic because we're passing in something we want to define but there's no "signal" that says we are. 14:12
so barring 'is parsed', we have to do something like the string quotes
on the callee end, I think we want something like a "symbol type" which can go in a slot like `class {{{$symbol}}}` or `sub {{{$symbol}}}` 14:13
passing in a string feels odd, but wrapping it in a symbol to say "this is something I want to declare here" feels about right
and there's prior art 14:14
beyond that, with the sub there's just the minor technical limitation that `quasi { sub foo { ... } }` defines a sub &foo *inside the quasi block*, which then gets spliced into mainline, but it's still just a lexical sub inside a block, so its scope/lifetime is pretty useless 14:16
if I were to express it, it's almost as if we want sub declarations to be unhygienic by default. 14:17
except I don't know if that's what we want.
FROGGS hmmm 14:18
I think I understand 14:20
masak consider the above a kind of snapshot of my thinking right now... :) 14:21
it's all the obstacles I see to have your use case 14:22
by the way, chances are 007 will implement your use case before Rakudo does
FROGGS after fiddling with CompUnitRepos (which is what I'm doing now), I want to hook into slangs again 14:25
which might let us play with macroish stuff too 14:26
masak aye 15:04
I think the macro story and the slang story should at least acknowledge each other, even if they end up being different-ish 15:05
from my perspective, just as a class is a group of subs that formed a hippie commune and a grammar is a group of regexes that formed a terrorist cell, a slang is a group of macros that formed a monastery. 15:06
...kind of. 15:26
FROGGS I can live with that :o) 15:38
bbiab
15:52 Ven joined 16:27 vendethiel joined 17:20 FROGGS joined