00:48 colomon joined 01:49 colomon_ joined 02:48 colomon_ joined 03:30 colomon joined 04:22 colomon joined 11:01 colomon joined 15:41 colomon joined 18:54 bkeeler joined, CokeBot9000 joined
jnthn OK, I think it must be about time :-) 19:01
Who's about?
TimToady I don't know anything about time. 19:02
moritz_ said he wouldn't be here 19:03
bkeeler I'm here
19:03 diakopter joined
jnthn OK, and colomon gave a maybe. 19:03
Quick report on what I've been up to in the last week... 19:04
Had weekend hackathon with masak++
Fixed some bugs with various escape sequences
Implemented interpolation of method calls and postcircumfixes in strings
Did the initial bits of work to get programs running with the setting as an outer lexical scope
Tossed some "our" decls 19:05
Some fallout that I need to deal with
There's more to come and it's Really Quite Tricky.
In Russia next week for two Perl 6 talks, got one in Malmö at the end of the month and will make the Nordic Perl Workshop and give a couple there, so lots of talk prep to distract me at the moment too. :-) 19:06
That's about all...
bkeeler: Is your regex interpolation work essentially just blocking on patch review?
bkeeler jnthn: Yep, pretty much 19:07
Just waiting patiently for some pm time
jnthn Well, thing is, moritz++ also has a patch in the same state.
bkeeler Which patch is that? 19:08
jnthn For allowing languages to have their own type of match object created.
bkeeler Ah yes, that'll be very useful
That was going to be my next thing, but he beat me to it 19:09
jnthn Thing is, there's no real way of knowing when we'll be fortunate enough to have some pm time. 19:10
I think at this point, I'll give both patches a look over to the best of my ability, and commit them.
TimToady well, if you put 'em in, and they pass, worst that can happen is that they get backed out later
jnthn TimToady: Right.
bkeeler Indeed. I'd say go for it, but for PM's dire warnings about the world sploding if it's applied as is 19:11
I'd like to hear at least a quick summary of his objections
TimToady well, and if that's the case, it might end up making more work for PM than waiting would
jnthn bkeeler: Is there such a warning on either of the patches, that you know of?
e.g. pm has said it's wrong in some way? 19:12
bkeeler Yeah, lemme see one sec
PM: "The patch is a very good start, but please don't apply it yet. I've only had a chance to do a preliminary review, but there are a few areas that need changing before the patch gets applied (otherwise we start painting ourselves into corners that may be difficult to get out of)." 19:13
TimToady that sounds dire enough 19:15
bkeeler yeah
jnthn Ugh.
OK.
bkeeler That was on 3/29 19:16
jnthn OK, I guess we should try and hold off a bit longer then. 19:17
With moritz's patch, I'll try and catch him about that one when he's online.
bkeeler I could review it also I guess
jnthn That would be helpful.
That one is kinda in the way of us being able to look at matches in Rakudo at the moment. 19:18
bkeeler His patch modifies nqp, right? 19:19
(trying to find it in RT...)
jnthn Yes, I believe so.
bkeeler It could also be achieved by subclassing NQP's cursor and overriding the !MATCH method I think 19:20
jnthn I guess TMTOWTDI 19:21
I didn't look over the patch yet.
I'm fairly sure that moritz_ and Pm had some discussion about the approach to this at some point, though. 19:22
bkeeler Also, I think the objects are supposed to be named Cursor, Regex and Match rather than Regex::[...] 19:23
jnthn Yes 19:24
TimToady: How are things coming along on the sink context front? 19:25
TimToady decided it had to be a least partly calculated in a pass subsequent to the parse, and started modifying std to do that, but didn't get very far, other than moving the autoloading AST routines to a separate file from viv 19:29
the reason you can't do it at parse time is that you don't know if you're current statement is the last one in its context (or the context around that (or the... 19:30
*your
jnthn Does it boil down to needing to have the whole program to look at, or is there some smaller boundary? 19:31
(I follow that blocks themselves certainly can't be that smaller boundary; I wonder more about routines.) 19:32
TimToady yes, routines are analyzable that way, to the extent that you can know at all what the caller wants 19:33
i.e. not 19:34
and potentially you have to be able to do it on a smaller scale as well in order to fold constants
but that could be with or after the routines analysis, I suppose 19:35
jnthn OK, so we're probably looking at a complete second pass over the AST?
(Don't really need for-sure answers now, but trying to get a picture of the kinds of things that we'll need :-)) 19:36
TimToady yes, for some definition of "complete" that could be piecemeal
(P5 always applies context to a subtree as soon as possible and then marks that subtree as done) 19:37
jnthn OK 19:38
TimToady well, at least last time I looked at it. :)
jnthn I'm not looking to iminently implement this, but I suspect we want it in before Rakudo *.
Otherwise we struggle with turning for into map I guess. 19:39
TimToady well, you struggle with applying eager to it 19:40
for and map should just compile down to the same thing
give or take
jnthn Well, yes, I meant for the "knowing when to eager it" part 19:42
I guess we could switch to map and .eager it all the time until we know not to. 19:43
TimToady it might be more useful to compile assuming sink context, and then retroactively mark the final statements as wanted, as long as sink doesn't do anything non-reversible
jnthn What does something being in sink context actually mean? 19:44
TimToady but you'd have to distinguish an implicit sink from an explicit one when stripping it back off
eager, but again, an explicit eager won't go away, but an implicit one does
jnthn That is, do we call .eager / .sink / whatever?
And then we have a default one that is just identity? 19:45
TimToady we can have .implicitsink that implies eager, and is recognizable enough to strip on the final statement if wanted
jnthn Well, I can tag the AST too, which is perhaps safer. 19:46
Otherwise masak++ will read the source and define an implicitsink method then submit masakbug. ;-)
TimToady yeah, you don't want to precommit to sink if it's going to make for bogus "useless use of" messages
jnthn Aye. 19:47
TimToady so maybe Sink/Float/TreadWater :)
jnthn But my question was more simply: we've (somehow) determinited that something certainly is in sink context. What should the code we generate actually do?
e.g. for 1..100 { .say }
Would compile to
TimToady the actual code just does .eager
jnthn oh, OK. 19:48
And is there a default .eager for things that already are?
And lazy things have a .eager that makes them so?
That is, does Mu have a method eager() { self }
TimToady maybe 19:49
eager seems like one of those "make it a list (or a denerate list of 1 item) if it isn't a list" kinda things
jnthn Aye, like the other contextualizers I guess. 19:50
TimToady so probably Any, if not Mu
jnthn I think we've got the others in Mu
So it's always safe to @(...) anything.
TimToady mkay
the "useless use of" analysis is orthogonal to what you run at run time 19:51
it only cares whether the top operation has side effects or not
+ has no side effects, therefore you can get "Useless use of +" 19:52
an assignment in sink context is fine though
pure ops also are part of the calculation of static subtrees for constant folding 19:53
but you also have to have static values to feed the pure ops
so pure ops is necessary but not sufficient for folding
jnthn I guess anybody silly enough to define a + with side-effects get what they deserve. :-)
moritz_ back
jnthn \\o/ 19:54
TimToady presumably the proto for operators will imply purity/impurity defaulted to the precedence level
STD already has :pure :!pure markers in the prec table
jnthn Ah, cool.
TimToady (but presumably any new op could override in its proto) 19:55
jnthn nod 19:56
TimToady things like logical ops have to delegate sinkness to their arguments though, so they are neither pure nor impure
anyway, purity marking can mostly happen as we reduce, but downward sink/float context propagation has to be later 19:57
jnthn *nod*
My plans for the next week or two are to try and get the lexical classes and roles sorted out, and deal with more lexical setting issues. There's some rather nasty stuff to do with BEGIN/INIT time and lexical scopes. :-( 19:59
TimToady time for cabal phone 20:00
jnthn :-)
moritz_ speaking of time...
I now have a regular event on Wednesday evenings 20:01
so it would be good for me to move #rs to Tuesday or Thursday
afk &
jnthn moritz_: That could well be do-able. I'm day agnostic.
bkeeler Me too
TimToady me three 20:03
20:07 diakopter left, bkeeler left
colomon o/ 20:20
PerlJam well crap. I tend to miss #rakudo-sketch even when I'm aware of the day and time 20:32
CokeBot9000 ( I should at this to the parrot calendar.) 20:38
21:40 colomon 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!