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 2 March 2015.
vendethiel I've known about scala's "thunk" equivalent for a while, but I'm not sure we discussed it 10:56
$ scala 10:58
scala> def foo(thunk: => Unit): Unit = for (i <- 1 to 3) thunk
foo: (thunk: => Unit)Unit 10:59
scala> foo(println("hey"))
<hey 3 times>
masak looks nice. 11:04
I don't know enough Scala, though. does the `for` syntax usually take a block? 11:05
vendethiel the {} are "implicit"
just like for the function 11:06
masak what makes you say it's a thunk rather than just a closure? could you, say, declare something in the thunk that's visible outside in the same scope? 11:54
vendethiel it's just because of how you call it 12:01
masak I don't know enough about Scala calling syntax... 12:03
12:48 Ven joined
masak I think 007 has made me think a bit more about different "axes" of programming, and how they have different strengths and tradeoffs. 13:39
like "lexical", "data" and "mro".
the lexical one is the really static one. 13:40
the data one can be made more static with a nice enough type system.
mro is fairly dynamic and open-ended.
macros fit mostly into the "lexical" axis, except in the ways that they subvert/corrupt it. 13:41
15:26 Ven joined 17:16 vendethiel- joined
vendethiel- masak: so the MOP is the equivalent or macros for mro? 19:59
Mouq macros seem to be about ...many things... but one thing is using the "lexical" bit as "data"… 20:08
masak vendethiel-: s/or/to/ in your question? are you asking "lexical axis":macros::"mro axis":mop ? 20:28
there are certainly some intications as to a "yes" answer, but I'm not 100% convinced of yes. could be just a coincidence.
for one thing, nothing about the MOP has BEGIN semantics. nothing about the MOP ties into parsing.
hm. 20:29
that gives me an idea.
maybe one way to systematically make macros better -- as my blogging effort is aiming to do -- would be to list all the *different* things macros currently do, or are believed to do. as precisely as possible. focusing on what they achieve rather than on exactly how they do it. 20:30
examples:
vendethiel- s/or/of/ 20:31
masak, actually, I think the fact that the MOP is late-bound instead of BEGIN-bound makes its duality with macro clearer
I'm referring to jnthn's talk here 20:32
masak "macros substitute certain invocations for some other Qtree"
vendethiel- "sub = your language, method = object's language"
...just like subs are BEGIN-time resolved, macros are;
masak "macros substitute certain operators (and their operands) for some other Qtree"
vendethiel- just as virtual calls are late-bound, MOP hackery is
masak "macros trigger at BEGIN time, as-soon-as-parsed"
"macros (can) affect the subsequent parse, after having seen the 'head word' (sub or op) that caused it to be called" 20:33
those are the ones I can think of right now.
Mouq I think that last one is what might tie it most to the "sub = your language, method = object's language", in a very literal way 20:44
But all of these things accomplish bits of that
vendethiel- right 20:45
Mouq continues to state the obvious :P
masak notice that due to the late-boundedness of mro, there's no such thing as a macro method. 20:48
Mouq Perhaps the fact that they don't intersect makes possibility of a parallel stronger 20:49
masak yes, perhaps.
the middle one, the "data axis", doesn't seem to do much at all except lookup. but it still feels like it belongs. 20:50
vendethiel- that was what I was talking about when I said "duality", btw
masak *nod* 20:51
Mouq .o( multi-dispatch macros… we already implement slangs in terms of OO, and this will only get stronger as slangs mature (I expect there'll be a Metamodel::SlangHOW) ) 20:55
Then again, maybe it's wrong to call grammars OO on a certain level 20:56
masak the Perl 6 grammars have started to feel more and more wrong to me as I've started thinking about language extensibility. 20:57
on the other hand, I don't have a good counter-proposal.
maybe I'm just vainly wishing there to be a good way to extend things arbitrarily without thereby breaking the encapsulation of the original implementation. 20:58
Mouq An idea came to mind of essentially user friendly AOP for grammars, but I doubt that's a good way to go :P 21:01
masak I don't know. 21:02
I think about this quite a bit.
no solution yet.
vendethiel- masak: what you're wishing for seems pretty hard indeed :-) 21:06
did you read papers on sugarj and so on?
masak not sure
vendethiel- I think that 21:07
Mouq I certainly think it would make sense that instead of Grammar.parse(…,:actions(Actions)), you have Parser.parse(…), and to change the actions via class MyParser does Parser { … #`[modify actions somehow] }
vendethiel- if you want to make something more extensible "by everything" you have to make it a bit easier to use/handle, maybe a tad more restrictive
like agda's operators -- they allow for crazy stuff, but the syntax to add one is simple and basic

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!