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 20 June 2015.
masak "goes in the way of"? please clarify. 09:31
anyway, I haven't forgotten that you said that. I still disagree, but I'm keeping it in mind.
vendethiel- hi!
masak o/
vendethiel- right time it seems :)
"goes in the way of" -- sorry, I phrased that poorly, I was tired. I meant -- I think it's going in the same direction I was 09:32
also, my argument really is -- it's all syntactic
masak well, we agree on that. 09:33
vendethiel- I can have a QCall('a') (that produces, well, a()), and there's no semantic involved here
which means a could be a sub or a macro
masak also true.
though...
vendethiel- which is why I think that "&&" being special an operator isn't an issue
the evaluation semantics are *not* encoded in the AST
masak also true.
...as far as I can understand, macro calls are too "volatile" to end up as Qtrees. 09:34
the moment they're parsed, the compiler goes away and finds out what to substitute.
vendethiel- really? That means I can't generate macro calls from macros, though
masak oh, maybe it's possible to synthetically generate macro calls. 09:35
that's a really good point.
vendethiel-: anyway, my objection to "ops and funcalls are the same" is that there are a lot of syntactically different things that are "the same" if you look under the surface, but that we don't want to declare equal on the Qtree level. 09:52
vendethiel- what do you have in mind? 09:53
(also, I don't think "operators being subs" is under the surface at all)
masak sub calls and method calls are pretty close. 10:07
as are sub declarations and method declarations.
or class decls and package/module decls. 10:08
vendethiel- mmmh. 10:11
but they interact differently with each other
I still feel bad about nesting methods, and feel like it should be disallowed :)
we had that discussion in #perl6 multiple times, though, and I know perl people usually argue that you should be able to shoot yourself anywhere you want
masak there's no known use for nesting methods. 10:12
they have... "interesting" closure characteristics.
I don't think I would ever use them in production code.
but I don't see anything wrong with them, per se. I think there is greater harm/risk in disallowing them than in leaving them be. 10:13
vendethiel- that's where I disagree 10:16
masak noted.
vendethiel- I don't think a "feature" that can only ever be wrong is a good idea
when the only time it *could* work is for "weird features in your language" contest
and when they're gonna trip up people
it's kind-of needed to be able to say "method", I guess, because of MOP .^add_method 10:17
I meant -- use the keyword method "anywhere"
masak the `method` keyword is already usable in a bunch of unexpected (but useful places). 10:26
see camelia eval on #perl6. 10:27
s/' places)'/) places/
vendethiel- mmh 10:33
> die "The associativity must be a string" 10:35
I beg to disagree :P
if there are only 5 possible values, it should be an enum 10:36
masak hehe.
I think there are only 3 possible values as of now.
vendethiel- left, right, list?
masak left, right, non. 10:37
are you equally outraged that there is no Bool type and that boolean values are represented by 0 and 1?
vendethiel- no, I hate booleans and numbers (and strings) equally :)
masak actually, when I wrote that `die`, I thought something else: it should be OK to put a constant there.
as long as the constant refers to a string. 10:38
but that's not on the critical path.
007 doesn't have enums. 10:39
vendethiel- fair enough :P
good point
the enum thing could work in P6 tho
masak aye. 10:42
that's not my biggest kvetch with associativity in p6, though.
vendethiel- obviously
I admit I don't define operators all that much ;)
> [12:08] <masak> or class decls and package/module decls. 10:43
but there's a semantic difference here
masak moreso than with op/funcall, yes. 11:11
vendethiel- there are implications as to using one instead of another 11:13
I don't think that's true for op/funcalls
masak I feel a general lack of solid reasons. 11:48
I can't really explain (a) why you prefer to consolidate ops/funcalls in Qtrees, nor (b) why I prefer not to.
vendethiel- because they're the same. you can interchange between them, without any semantic difference 12:10
(syntactic ones, sure)
masak but that is true of `foo($a, $b)` and `$a.&foo($b)` too. 12:12
and I don't feel a need to conflate *those*, either. 12:13
my point is that, even though they are unified fairly early on in the process -- and I agree that they are -- it makes more sense to keep them separate among the Qtree types. 12:14
ISTR I almost managed to sway you once by pointing out it'd simply be too surprising if we did a search for function calls in the code (maybe in order to do a refactor or something), and we got all the ops in the search result, too.
that kind of surprise is the sign of a bad API. in this case, the cardinal sin of trying to be too clever too early. 12:15
vendethiel- the only thing I can think of right now is "mhhhhhhhhhhhhhhhhhhhhhhhhhh" 12:20
masak so you agree :P 12:21
vendethiel- no!
I still think that, if Perl6 pretends that operators are just subs, it should go all the way with that 12:22
I'm just trying to think of other languages that have this kind of features
I however agree that it'd be surprising to have a search come up with both
masak I agree with what you just said, but... 12:23
I think it's Qtree that you have the wrong expectations of.
Qtree is not the place to make that equivalence. 12:24
it's there to serve the user, not to make a point about semantic equivalence.
vendethiel- fair enough
you decide where you put that one cursor :)
will it even matter that much? I don't think so 12:25
masak I see the main goal here as satisfying a number of simple use cases involving the introspection and transformation of source code. 12:26
vendethiel- really, it all depends on how much you want to encode semantics vs encoding syntax 12:27
masak almost entirely the latter. at least to a first approximation.
vendethiel- then, sure, there's a point to having a different type for op applies and funcalls 12:28
masak but I also want Qtrees to be involved in semantics. for example, if a variable is referenced in an expression, it should be just a matter of a method call to find that variable's definition.
or a class and its definition. etc. 12:29
basically anything that's statically knowable should also be easy to navigate through the Qtree.
vendethiel- oh, uhm.
masak it's an open question to me exactly how all this intersects with the MOP.
vendethiel- strangely enough, it's not the part that scares me 12:30
just like subs vs methods are different "languages" (re jnthn), I feel like the MOP and the macro system are equivalent
but I think I said that at some point already :)
(equivalent in that -- macros are for subs, MOP are for methods) 12:31
masak I don't think I agree with that. 12:32
vendethiel- good!
masak MOP is serving the *semantics* of most things in Perl 6 involving types, OO, and objects.
vendethiel- okay, i'll rephrase
masak Qtree is serving the *syntax* of the program text, connecting it back to interesting things like values and definitions.
vendethiel- macro = the meta-ability to change syntax. MOP = the meta-ability to change objects' inner workings 12:33
masak ok, agree. as far as that goes.
vendethiel- MOP kicks in where the macros won't have enough information to statically "understand" the code 12:34
in that, objects are late-bound things, blablablabla
so I won't effectively be able to say QCall.where-is-that-sub-defined
masak you will, for subs. 12:36
except of course the things might be multis, so it might be a complicated answer. 12:37
vendethiel- yeah, when I say I won't be, I still meant in objects realm 12:40
masak ...which is why there's one type of Qtree node for function calls, and one for method calls ;) 12:41
vendethiel- you're right that we have the same issues with multi, though. eeh.. 12:42
masak well, with multi, the correct question isn't "which sub gets called" 12:43
it's more like "where's the (possibly implicit) proto defined"
or maybe "where's the set of all multi candidates under this proto" 12:44
both of which are statically knowable
12:44 Ven joined 12:48 Ven joined
Ven seems like it! 12:50
masak I *love* how multi candidates can be defined in an inner scope, and... then they just go out of scope, and you're left with the old set again. 13:00
it's very very pretty. well-designed.
Ven right :)
I was just *trying* 13:01
masak walk & 13:35
16:33 Ven joined 18:31 vendethiel joined 20:04 vendethiel joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!