01:21:07  * caitp-joined
01:26:39  * caitp-quit (Ping timeout: 244 seconds)
02:45:31  * mooseboobsjoined
03:23:52  * caitp-joined
03:28:35  * caitp-quit (Ping timeout: 244 seconds)
03:49:30  * ashnurquit (Remote host closed the connection)
03:51:53  * ashnurjoined
03:57:55  * muellijoined
03:58:33  * caitpquit (Ping timeout: 244 seconds)
04:09:05  * muelliquit (Ping timeout: 265 seconds)
04:25:00  * caitp-joined
04:30:04  * caitp-quit (Ping timeout: 244 seconds)
04:32:39  * caitpjoined
04:39:22  * caitpquit (Ping timeout: 244 seconds)
04:40:31  * mooseboobsquit
04:50:30  * Vbitzquit (Quit: ZNC - http://znc.in)
05:14:54  * Vbitzjoined
05:31:23  * caitp-joined
05:35:41  * caitp-quit (Ping timeout: 244 seconds)
05:51:13  * mooseboobsjoined
06:37:54  * guorquit (Ping timeout: 256 seconds)
07:08:43  * guorjoined
07:20:23  * caitp-joined
07:24:42  * caitp-quit (Ping timeout: 244 seconds)
07:29:03  * wingojoined
07:33:26  * mostynbjoined
08:01:44  * jochen__joined
08:51:00  * Lethalmanjoined
09:04:02  * dobsonquit (*.net *.split)
09:06:10  * dobsonjoined
09:09:23  * caitp-joined
09:13:43  * caitp-quit (Ping timeout: 244 seconds)
09:25:06  <trungl-bot>Tree opened by [email protected]: Tree is open (CQ failure http://crbug.com/465208)
10:27:19  * totemizerjoined
10:27:24  * ashnurquit (Ping timeout: 272 seconds)
10:47:14  * tiglionabbitjoined
10:58:26  * caitp-joined
11:02:44  * caitp-quit (Ping timeout: 244 seconds)
11:09:48  * tiglionabbitquit (Quit: tiglionabbit)
11:24:15  * Net147joined
12:02:05  * mostynbquit (Remote host closed the connection)
12:29:28  * caitp-joined
12:33:40  * caitp-quit (Ping timeout: 244 seconds)
12:35:47  * totemizerchanged nick to ashnur
12:35:56  * ashnurquit (Changing host)
12:35:56  * ashnurjoined
12:36:57  * bnoordhuisjoined
13:20:28  * caitpjoined
13:24:08  * bnoordhuisquit (Ping timeout: 264 seconds)
13:33:53  * caitpquit (Ping timeout: 246 seconds)
13:41:22  * caitpjoined
13:45:06  <trungl-bot>Tree opened by [email protected]: Tree is open (CQ problems resolved)
13:45:59  * Net147quit (Quit: HydraIRC -> http://www.hydrairc.com <- IRC with a difference)
14:09:55  * jsguijoined
14:15:12  * caitp-joined
14:20:06  * caitp-quit (Ping timeout: 244 seconds)
14:27:49  * KillerJimjoined
14:30:39  * bnoordhuisjoined
14:35:32  * bnoordhuisquit (Ping timeout: 264 seconds)
15:28:18  * ashnurquit (Ping timeout: 256 seconds)
15:28:33  <caitp>marja___, what's your opinion on adding some limited backtracking to the parser?
15:28:46  <caitp>I think I need it for adding rest param support to arrow functions
15:29:45  <marja___>caitp: it's kinda tricky... hmm, it was on the table once, and we concluded that at least the solution we had in mind just exploded (the backtracking was in no way "limited" any more, since the constructs can nest)
15:30:08  <marja___>in addition, not all the parser data streams are rewindable (though, they can be made rewindable)
15:31:03  <caitp>the idea I had in mind was, not actually rewinding the streams
15:31:04  <marja___>but hmm, this was in the context of default parameters.
15:31:21  <marja___>so maybe the situation you need to solve is easier and doesn't end up in pathological cases like that.
15:31:21  <caitp>just making sure not to update the stream when calling next() in a backtracked position
15:32:11  <marja___>alright, so, how would it work overall? when would we decide to backtrack, what would it mean, etc.
15:32:31  <caitp>well mozilla's approach to it is to look for `... <identifier> ) =>` when parsing a primary expression --- which would work great, but I'd need to backtrack so that the closing paren can be parsed right
15:35:47  <marja___>so it'd parse those, then push => and ) back?
15:36:19  <caitp>https://gist.github.com/caitp/444ab494e6425b847824 something like that I guess
15:36:30  <marja___>and then ParsePrimaryExpression would consume the )
15:36:40  <marja___>... so you'd basically need a longer lookahead?
15:36:51  <caitp>yeah I guess
15:37:11  <caitp>same thing, different way of expressing it
15:37:13  <marja___>yea
15:37:14  <aperezdc>fwiw, it looks like “some more lookahead” to me, too
15:37:44  <marja___>okay, so that case seems unproblematic compared to the pathological default param cases.
15:38:28  <marja___>especially since the tokens looked-ahead are so simple... i'm not sure how much complicated it would be if we'd need to long-peek or push back strings etc.
15:39:04  <caitp>i guess my worry is about making the parser slower for everyone if it needs to be able to deal with more state
15:39:44  <marja___>q: would you do something different if you see "... <identifier>" than if you see "... <identifier>) =>"
15:40:11  <marja___>do we actually need to know that there are ) and =>, or can we set some "saw rest param" state, which will then make subsequent phases fail if there are no ) or =>
15:40:49  <marja___>(or somehow set the "is rest param" flag to a thing which is <identifier>)
15:40:57  <caitp>if the next token after an identifier isn't a ")", then it should be an error and doesn't need to scan further
15:41:17  <caitp>or i mean, doesn't need to look further ahead
15:41:42  <marja___>yea, ParsePrimaryExpression should handle that anyway (if it has seen "(")
15:42:00  <marja___>so i'm still not sure what difference the increased lookahead would make
15:42:23  <marja___>like, would it be possible to handle it with some other means
15:42:42  <caitp>I think the idea is that ParsePrimaryExpression is called during the parsing of a binary expression with , op
15:43:44  <marja___>ah yeah, we were probably talking about different levels of ParsePrimaryExpression. so there's one for "( thing )", and that's the one that consumes the )
15:43:52  <caitp>so ParsePrimaryExpression wouldn't deal with the ()
15:44:34  <marja___>so you'd like the one which parses "...rest" and you'd like that to only succeed if it's followed by ) =>
15:45:05  <caitp>yeah, but then be able to resume parsing from the ) instead of from the =>
15:45:14  <marja___>yep
15:46:16  * caitp-joined
15:46:32  <marja___>an alternative solution would be to always accept "...stuff" and set the "this is a rest parameter" flag to the relevant entity, but then, i can see that it can be horrible to always check that flag in all places.
15:46:50  <marja___>otoh, maybe it can be passed forward
15:47:00  <marja___>when we're parsing something that's potentially an arrow function parameter list
15:47:10  <marja___>(i.e., we have seen the "(")
15:47:26  <marja___>afaics that could also work
15:47:38  <caitp>yeah but you still end up worrying in a lot more places about a SpreadOperator ast node that shouldn't be ther
15:47:39  <caitp>e
15:47:47  <caitp>or a flag on a different token
15:48:07  <marja___>yeah, hard to say in advance which solution is better
15:48:25  <caitp>I thought it was nice to at least for now group things that way so that there's a limit to where the nodes can turn up
15:49:06  <marja___>otoh, the "increase peeking distance" solution is only slightly horrible and afaics doesn't necessarily make things slower
15:49:31  <marja___>(we'd just keep 4 tokens in memory instead of 2, and when we Next() we'd advance in the queue)
15:49:43  <marja___>(i assume that scanning a token would dominate the queue handling, but otoh, that might not be true)
15:50:05  <marja___>(nah, it will)
15:50:29  <marja___>plus we'd potentially need to keep 4 strings or such, brr.
15:50:53  <caitp>hm
15:51:02  <marja___>that'll be a hassle with the literal buffers... so we probably want to somehow selectively be able to peek further
15:51:02  * caitp-quit (Ping timeout: 244 seconds)
15:51:09  <marja___>and not always peek 4 tokens far
15:51:30  <marja___>idk, i don't have a clear opinion now what solution is the most elegant. :/
15:51:44  <caitp>i guess I'll try some things
15:52:29  <marja___>alright
15:52:39  <marja___>i guess the real horror will start when the default params emerge :/
15:57:43  <caitp>why is it needed for default parameters though?
15:57:58  <caitp>i guess in arrow functions it is
16:00:50  * octetcloudjoined
16:08:05  * ashnurjoined
16:12:32  * RT|Chatzillaquit (Quit: ChatZilla 0.9.86.1 [Firefox 2.0.0.22pre/2009081014])
16:17:21  <trungl-bot>Tree closed by [email protected]: Tree is closed (Automatic: "bot_update" on http://build.chromium.org/p/client.v8/builders/V8-Blink%20Win/builds/2552 "V8-Blink Win" from ea2f15e2a9e0075d48219cd9f21a0399a55e16cf: [email protected])
16:19:49  <marja___>hmm, so, let's see... when we're parsing an arrow function param list, we don't yet know that we're parsing an arrow function param list... we'd only know that after we see =>. and at that point, we need to convert whatever we have parsed (which might have a default param - we need to accept that when we see it) into an arrow func param list. so at some point there was this idea on the table that "if we detect it's an arrow function param list,
16:19:49  <marja___>let's just go back and parse it again" but that didn't fly.
16:20:11  <marja___>... but your stuff is not "parsing stuff again" except in a very limited manner for the peeked ) and =>
16:25:25  <trungl-bot>Tree opened by [email protected]: Tree is open (Automatic: ʕ •ᴥ•ʔ)
16:29:39  * xiinotulpjoined
16:33:25  * plutoniixquit (Ping timeout: 265 seconds)
16:45:16  * bnoordhuisjoined
17:01:49  * rendarjoined
17:02:18  * caitp-joined
17:02:33  * mostynbjoined
17:06:59  * caitp-quit (Ping timeout: 244 seconds)
17:30:01  * xiinotulpchanged nick to plutoniix
17:31:11  * KillerJimquit (Quit: Leaving)
17:33:38  * tiglionabbitjoined
17:46:18  * Lethalmanquit (Quit: Sto andando via)
18:02:21  * mooseboobsquit
18:05:10  * tiglionabbitquit (Quit: tiglionabbit)
18:23:17  * bnoordhuisquit (Ping timeout: 250 seconds)
18:29:39  <caitp>hmm, I think it's going to be a very messy diff =\
18:37:01  * tiglionabbitjoined
18:51:30  * caitp-joined
18:55:42  * tiglionabbitquit (Quit: tiglionabbit)
18:56:00  * caitp-quit (Ping timeout: 244 seconds)
18:57:14  * octetcloudquit (Ping timeout: 272 seconds)
18:57:55  * bnoordhuisjoined
19:05:47  * octetcloudjoined
19:32:42  * KillerJimjoined
19:47:44  * wingoquit (Ping timeout: 246 seconds)
19:50:47  * tiglionabbitjoined
20:07:23  * caitp-joined
20:11:57  * caitp-quit (Ping timeout: 244 seconds)
20:36:01  * wingojoined
21:02:04  * rendarquit (Ping timeout: 256 seconds)
21:07:40  * rendarjoined
21:08:24  * caitp-joined
21:12:55  * caitp-quit (Ping timeout: 244 seconds)
22:09:47  * caitp-joined
22:13:53  * caitp-quit (Ping timeout: 244 seconds)
22:18:42  * plutoniixquit (Quit: จรลี จรลา)
22:30:34  * RT|Chatzillajoined
22:40:36  * wingoquit (Ping timeout: 246 seconds)
22:56:57  * caitp-joined
23:52:11  * KillerJimquit (Quit: Leaving)
23:55:25  * octetcloudquit (Ping timeout: 252 seconds)