Perl 6 - the future is here, just unevenly distributed

IRC log for #6macros, 2015-06-21

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

All times shown according to UTC.

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

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