|
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. |
|||
|
00:29
vendethiel joined
01:14
vendethiel joined
02:07
vendethiel joined
05:18
vendethiel joined
05:24
vendethiel joined
06:14
vendethiel joined
06:37
vendethiel joined
06:56
Ven joined
07:16
vendethiel joined
07:17
Ven joined
|
|||
| Ven backlogs | 07:22 | ||
| masak | today's question for pondering/discussion: how should Q::Class look? | 08:04 | |
| a lot of info "hangs off of" this type of Qtree node. | 08:08 | ||
| just yesterday I was made aware of `hides`, for example. | |||
| Ven | yeah, I saw that in the backlog. | ||
| that's why I kinda want to leave the main use cases to the MOP | 08:09 | ||
| for stuff like "monitor"...should that be a Q::Class? | |||
| masak | "leave the main use cases to the MOP" is a valid answer, I think | 08:10 | |
| but it also feels like retreating a little | |||
| does a pure Perl 6 code parser need to have a MOP? should it? | |||
| good quesiton about `monitor`. I don't know offhand. | |||
| Ven | I mean, a macro should offer some capabilities for sure. | 08:13 | |
| it should probably have a "is" fields? and some attributes? and a methods one? | 08:14 | ||
| what does this look like, AST-wise? | |||
| class A { method b { method c { 3 } }; } ? | |||
| if we still stay on the same "it's all syntactic" track, it should simply have a method nested in another one | 08:15 | ||
| but this would surprise people | |||
| masak | you would ask the class what methods it has. | ||
| it would find them regardless of nesting depth. | |||
| (but it wouldn't find, say, the methods in nested classes) | |||
| that kind of thing is what I'm after. basically providing good ways to find things the way a human thinks about the code. | 08:16 | ||
| Ven | well, then it's more than "just syntactic" | 08:21 | |
| and you're messing with the MOP | |||
| Ven would like TimToady / jnthn's input | |||
| (s) | |||
| masak | not sure about "messing with" | ||
| more like overlapping concerns | 08:22 | ||
| whether that's problematic or not, I don't know | |||
| Ven | yes, sorry. | ||
| WELL. the question. the big question | |||
| can we make both Work Together™? | |||
| masak | aye | ||
| Ven | that'd be a killer feature | 08:23 | |
| masak | aye | ||
| Ven | but that might be too much to ask for | ||
| masak | dunno | ||
| Ven | I thought you might be interested by something | ||
| it's some crystal | |||
| lemme find it again... | |||
| masak | you raise a good point -- can we make them work together? | ||
| I hadn't really thought of Qtrees "messing with the MOP". but I guess they do. | |||
| I don't necessarily see that the converse is true. | 08:24 | ||
| Ven | gist.github.com/bcardiff/a663b1ea1e8fd6a308cc | ||
| dumping crystal AST nodes by monkey-patching a macro inside of Crystal::ASTNode | |||
| no, indeed, the MOP doesn't need to "see" the tree | 08:27 | ||
| masak | sorry, I'm a bit tied up in a meeting, actually | 08:28 | |
| I'll look at the gist later :) | |||
| so if Qtree has an implicit connection with the MOP, what's supposed to happen if the Qtree induces a change on the MOP after the MOP already changed independently through some other means? | |||
| feels like it becomes a question about "who owns the data", as it often does | 08:29 | ||
| Ven | alrigt | 08:38 | |
| ht* | |||
| I still stand by the fact I'd like some input from TimToady and jnthn, though... | 08:43 | ||
| masak | yes, sure. me too. | 08:49 | |
| in some sense, we have to face this problem, I think. | 08:50 | ||
| because the Qtree is meant to be a read/write representation of the program. | |||
| Ven | yeaaah. | ||
| "but" | |||
| there's an insane amount of clash | 08:51 | ||
| masak | nodnod | ||
| something we need to address, for sure | |||
| I still feel like even though there's a lot of overlap, Qtree and MOP still fill very different purposes | 08:52 | ||
| maybe some sensible restrictions have to be drawn up. like "you can't change this Q::Class object, because the '}' of the class has already been seen and the MOP metaobject has already been released into the world" | 08:53 | ||
| Ven | yeah... | 09:23 | |
| also... | |||
| it's fighting that "macros are syntactic" barrier | |||
| maybe we should just tell people to run their MOP code in BEGIN blocks, and that they don't actually need macros for that | |||
| ....which very well might make sense | |||
| we should ask for someone's use case | |||
| masak | I know some use cases. | 09:38 | |
| "autogenerate some methods with these names and these bodies" is a common one. | 09:39 | ||
| that would likely happen inside of the class block, though | |||
| Ven | yeah, but, you can mostly do that with the MOP | 09:40 | |
.oO( BEGIN EVAL ) :P |
|||
| masak | not with clean syntax, is the point. | ||
| Ven | right, right, yes | ||
| masak | people want to be able to `mymethod foo;` and that's it | ||
| walk & | 09:43 | ||
|
10:53
Ven joined
10:56
Ven_ joined
11:19
Ven joined
|
|||
| Ven is back | 11:21 | ||
| masak too | 11:25 | ||
| masak checks if he has a post about "Qtree/MOP overlap" queued up on his list | 11:30 | ||
| ...I do now. :) | 11:34 | ||
| hey, maybe total hygiene is the wrong default for Perl 6 macros? | 11:42 | ||
| people keep doing `quasi { sub foo() { ... } }`, and then expecting the sub &foo to have been declared in the mainline. | 11:43 | ||
| actually, that seems a very common use case for macros. | |||
| so maybe hygiene should be *off* by default (eliminating some heavy realiance on COMPILING::) | 11:44 | ||
| but people should be encouraged to think about when they can introduce blocks to avoid collisions | |||
| ...maybe? I dunno | |||
|
14:55
ilbot3 joined
|
|||
| moderator | 6macros: discussing the finer points of Perl 6 macros, Qtrees, and how to stay sane | irclog: irclog.perlgeek.de/6macros/today | ||
|
15:07
vendethiel joined
16:10
Ven joined
16:32
Ven joined
17:05
vendethiel joined
20:41
vendethiel- joined
|
|||