Perl 6 - the future is here, just unevenly distributed

IRC log for #6macros, 2015-03-05

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

All times shown according to UTC.

Time Nick Message
10:56 vendethiel I've known about scala's "thunk" equivalent for a while, but I'm not sure we discussed it
10:58 vendethiel $ scala
10:58 vendethiel scala> def foo(thunk: => Unit): Unit = for (i <- 1 to 3) thunk
10:59 vendethiel foo: (thunk: => Unit)Unit
10:59 vendethiel scala> foo(println("hey"))
10:59 vendethiel <hey 3 times>
11:04 masak looks nice.
11:05 masak I don't know enough Scala, though. does the `for` syntax usually take a block?
11:05 vendethiel the {} are "implicit"
11:06 vendethiel just like for the function
11:54 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?
12:01 vendethiel it's just because of how you call it
12:03 masak I don't know enough about Scala calling syntax...
12:48 Ven joined #6macros
13:39 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 masak like "lexical", "data" and "mro".
13:40 masak the lexical one is the really static one.
13:40 masak the data one can be made more static with a nice enough type system.
13:40 masak mro is fairly dynamic and open-ended.
13:41 masak macros fit mostly into the "lexical" axis, except in the ways that they subvert/corrupt it.
15:26 Ven joined #6macros
17:16 vendethiel- joined #6macros
19:59 vendethiel- masak: so the MOP is the equivalent or macros for mro?
20:08 Mouq macros seem to be about ...many things... but one thing is using the "lexical" bit as "data"…
20:28 masak vendethiel-: s/or/to/ in your question? are you asking "lexical axis":macros::"mro axis":mop ?
20:28 masak there are certainly some intications as to a "yes" answer, but I'm not 100% convinced of yes. could be just a coincidence.
20:28 masak for one thing, nothing about the MOP has BEGIN semantics. nothing about the MOP ties into parsing.
20:29 masak hm.
20:29 masak that gives me an idea.
20:30 masak 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 masak examples:
20:31 vendethiel- s/or/of/
20:31 vendethiel- masak, actually, I think the fact that the MOP is late-bound instead of BEGIN-bound makes its duality with macro clearer
20:32 vendethiel- I'm referring to jnthn's talk here
20:32 masak "macros substitute certain invocations for some other Qtree"
20:32 vendethiel- "sub = your language, method = object's language"
20:32 vendethiel- ...just like subs are BEGIN-time resolved, macros are;
20:32 masak "macros substitute certain operators (and their operands) for some other Qtree"
20:32 vendethiel- just as virtual calls are late-bound, MOP hackery is
20:32 masak "macros trigger at BEGIN time, as-soon-as-parsed"
20:33 masak "macros (can) affect the subsequent parse, after having seen the 'head word' (sub or op) that caused it to be called"
20:33 masak those are the ones I can think of right now.
20:44 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 Mouq But all of these things accomplish bits of that
20:45 vendethiel- right
20:45 * Mouq continues to state the obvious :P
20:48 masak notice that due to the late-boundedness of mro, there's no such thing as a macro method.
20:49 Mouq Perhaps the fact that they don't intersect makes possibility of a parallel stronger
20:49 masak yes, perhaps.
20:50 masak 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
20:51 masak *nod*
20:55 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:56 Mouq Then again, maybe it's wrong to call grammars OO on a certain level
20:57 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 masak on the other hand, I don't have a good counter-proposal.
20:58 masak 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.
21:01 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:02 masak I don't know.
21:02 masak I think about this quite a bit.
21:02 masak no solution yet.
21:06 vendethiel- masak: what you're wishing for seems pretty hard indeed :-)
21:06 vendethiel- did you read papers on sugarj and so on?
21:06 masak not sure
21:07 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] }
21:07 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
21:07 vendethiel- like agda's operators -- they allow for crazy stuff, but the syntax to add one is simple and basic

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