[10:57:25] morning/afternoon! [11:00:50] hello! [11:02:29] nzakas1: ikarienator caridy1 ariya ready? [11:02:37] ready [11:02:40] seems like a short agenda today [11:02:44] hai [11:02:48] Hi jeffmo [11:03:06] Anyone have interesting updates since last meeting? [11:03:29] I have no progress nor updates [11:03:35] same here... [11:03:53] Same. Mostly heads down on flow-modules and class properties proposal here [11:04:18] ikarienator: has the cover grammar for destructuring done [11:04:26] I think destructring from @ikarienator mostly looks really good [11:04:35] yeah, that was a huuuge one [11:04:57] nzakas1: do you have any tests you can share with us for destructuring? [11:05:05] Want to make sure we have good overlap there [11:05:33] yeah, I think we added a few along the way [11:05:46] nzakas1: just point me to some source files? [11:06:18] I think this commit has the tests we made: https://github.com/eslint/espree/commit/0ddf4929be7897b410aad4d1ac9a7d1b3ddc2232 [11:06:40] in general, destructuring tests are here: https://github.com/eslint/espree/tree/master/tests/fixtures/ecma-features/destructuring [11:06:55] ikarienator: see if you can incorporate some of those, lets make sure we catch any bugs in each others impls [11:07:37] as far as template strings go [11:08:00] there were a few bugs in harmony, mostly around LegacyOctalLiteralEscapeSequences [11:08:31] we've landed on `\08` and `\09` and `\9` and `\8` being errors even though v8 currently excepts them [11:08:54] Anyone object to that? [11:09:01] ikarienator: thanks for sticking with me on that one :-) [11:09:06] I'm the layman here [11:09:21] no objections here [11:09:25] Firefox/SM also rejects that [11:09:30] aka, \08 is an error there [11:09:37] * jeffmo doesn’t pay close enough attention to text encoding to have opinions here [11:09:51] thus, any cross-browser JS code will avoid it anyway [11:09:57] ok, just making sure [11:10:24] nzakas1: you'll have to back port there, just as a heads up [11:10:30] yup [11:10:32] That is, if you care about that bug [11:10:38] which you may not :-) [11:10:55] breaks that nice consolidation the implementor in espree had :-\ [11:12:15] mikesherov: other than that, template literal is ready for landing? [11:12:25] yeah, in both master and harmony [11:12:31] been trying to be a good citizen there [11:12:46] harmony is going to miss ikarienator's destructuring though :-( [11:13:35] ok, next topic then? [11:13:40] Hi [11:13:46] hi ikarienator :-) [11:14:00] https://github.com/estree/estree/pull/57 [11:14:08] lets settle on landing superExpression? [11:14:23] SM has said they'll follow us [11:14:53] is it going to be for Esprima 2.x or 3.0? [11:14:57] we already shipped classes [11:15:04] 3.0 [11:15:13] sounds good then [11:15:22] note that it is not possible to have a transition here [11:15:22] yeah, I'll file esprima issue [11:15:25] it will be quite confusion [11:15:38] I disagree [11:15:52] nzakas1: do tell [11:15:53] no more confusing than shipping "name" and then changing to "id" [11:16:05] traversals will still work [11:16:10] nzakas1: name? [11:16:17] yup, for class [11:16:20] right [11:16:26] was that in a release? [11:16:39] What is SuperExpression? [11:16:52] https://github.com/jquery/esprima/issues/1095 [11:16:53] I think super is never an expression [11:17:10] nzakas1: CMIIW but 2.1 is already using id [11:17:27] yup, after 2.0 used name [11:17:40] ikarienator: https://github.com/estree/estree/issues/54 [11:17:43] that's a much more breaky than adding SuperExpression (or equivalent) [11:17:43] That was my bad... [11:18:01] no, 2.1.0 had the correct thing [11:18:07] nzakas1: 2.0 never had class [11:18:10] no released version of esprima had wrong thing [11:18:22] But yes, SuperExpression is wrong name [11:18:25] ah, hmmm, ok, I got confused [11:18:27] it should just be Super [11:18:28] mikesherov: my point ^^^ [11:18:40] ariya: I'm agreeing :-) [11:18:59] michaelficarra: made point about SuperExpression just being named Super [11:19:07] because it's not an expression [11:19:42] and we can avoid mess where everyone thinks its liskov substitutible for another expression [11:20:07] anyway, we'll add in 3.0 then [11:20:27] sounds good [11:21:16] ok, moving on [11:21:18] We shall actually add tests from Shift. [11:21:34] ikarienator: which tests? [11:21:44] for destructuring :-) [11:21:49] ikarienator: is catching up :-) [11:21:51] Yes [11:22:02] Sorry about that [11:22:10] ikarienator: both [11:22:27] we want to catch espree bugs too if we are to be good upstream parents to nzakas1 [11:22:41] and jeffmo :-) [11:23:21] nzakas1: is https://github.com/eslint/espree/tree/master/tests/fixtures/ecma-features/destructuring all the tests for destructuring? [11:23:39] those are all the tests for just destructuring [11:23:47] there are some that mix destructuring with other features [11:24:10] see: https://github.com/eslint/espree/tree/master/tests/fixtures/ecma-features-mix and search for "destructuring" [11:24:57] Ah nice! [11:25:25] ok, so can we move on? [11:25:43] Lets talk 2015 goals for a moment [11:25:52] Full ES6 support! [11:26:12] One thing about being in the jQuery Foundation is that we are *supposed* to provide goals to the foundation so they can allocate funds if necessary [11:26:21] or garner support in other ways [11:26:29] solicit help from other orgs, etc. [11:26:52] Full ES6 Support is defintiely a goal. I think we should aim to get that done though before ES6 comes out [11:26:59] like in next 2 months [11:27:10] definitely [11:27:38] so, lets say by June 1st the latest? [11:27:51] does that seem too aggressive, not aggressive enough? [11:27:54] fits into the “summer edition” [11:28:07] sounds sensible [11:28:12] that would culminate with last in 2.0 line, and release of 3.0 [11:28:19] there could be still a long tail of bug fixes etc [11:28:23] sure [11:28:33] we still don’t have a good plan for those pesky early errors [11:28:35] but get same level of support as espree and acorn [11:28:51] ariya, sure, but we've nailed almost all big chunks save for generators now [11:29:02] module as well [11:29:10] caridy1: ahem :-) [11:29:13] ;-) [11:29:30] ariya: if our two-phase parsing experiment in Shift goes well, you'll probably want to adopt that approach for early errors in esprima [11:29:38] michaelficarra: yes [11:29:44] we are watching closely :-) [11:29:45] for everyone reference: https://github.com/jquery/esprima/issues/1099 [11:29:57] michaelficarra: sure [11:30:31] michaelficarra: it already goes well for typescript (albeit it’s more its diagnostic, not strictly errors only) [11:30:47] https://github.com/estree/estree/pull/32 is a blocker to new.target [11:30:54] let's try to resolve that as well today then too? [11:31:22] seems like last real blocker [11:31:29] actually, we're getting sidetracked [11:31:34] back to goals for a moment [11:31:51] so we're going to have last of 2.0 line by June 1st [11:32:29] and release 3.0 with whatever EsTree corrections we need to have, and any other BC changes (removing guardedhandlers and handlers) [11:32:40] true [11:32:49] I'd like to then add another goal [11:33:05] ES7? [11:33:08] :-) [11:33:25] *without* devolving into 2 pass parsing and discussions of complexity, I really really think we need a way to allow people to specify ES5 or ES6 [11:33:32] @mikesherov, I will get the modules done before going on sabbatical, on april. [11:33:40] the dumb easy way is literally just release esprima 1.2.5 as esprima-es5 [11:33:44] caridy1: take your time, let me know if you need some help [11:33:50] thanks caridy1 [11:33:59] mikesherov: run-time language choice? I think it’s fair [11:34:01] caridy1: sabbatical!? [11:34:27] like literally, we can release esprima-es5 and that solves this whole mess (until es7) [11:34:49] and with es7, we can figure out best approach, as feature flags might be only option there [11:35:15] are you referring to one package that supports ES5 + ES6? [11:35:17] but honestly, I'm getting lots of requests in JSCS for es5 only mode, and it's preventing me from upgrading to esprima 2.1 [11:35:40] I'm referring to anything other than having the package named esprima support es5 modfe [11:35:48] surething [11:35:58] I also want to understand more on that ES5 mode for JSCS [11:36:03] literally, having a semver mean language difference is the only solution that *doesn't work* [11:36:25] it's why jQuery rebranded jquery 1.x and jquery 2.x as jquery-compat 3.x and jquery 3.x [11:37:08] people expect style enforcers, even if they are just style enforcers, to throw up when they use imaginary language features [11:37:11] mikesherov: so not divolving into 2-pass parsing seems a bit unfair since that is a member of the set of solutions to the “es5” vs “es6” discussion [11:37:24] jeffmo: we devolved on that last week [11:37:29] to be fair, I don’t think we want to add new language features to 1.x [11:37:33] ES5 doesn’t move anymore [11:37:33] just trying to discuss alternate approach [11:37:39] ariya, that's my point [11:37:39] mikesherov: ok [11:37:50] we just release 1.2.5 as esprima-es5 [11:37:53] and then I'm happy [11:38:03] I can have JSCS depend on both esprima-es5 and esprima [11:38:09] and the controversy is done [11:38:15] I think it's OK to have divergence in 1.x branch, so I think keep them separate is a good idea to me. [11:38:17] didn’t I propose this some time ago? :-) [11:38:18] https://gist.github.com/ariya/0d465b26113981c4eef1 [11:38:24] ariya you did :-) [11:38:37] I am now agreeing with you on that because feature flags is a sticking point for us [11:38:45] and 2 pass approach is too experimental [11:38:54] I think this will be the least confusion solution. [11:39:08] if we want to be pragmatic, sure [11:39:19] it doesn’t mean that feature flags or language flags are out of the question [11:39:20] A language flag can introduce a lot of bugs and performance issues. [11:39:23] I don't think we need wrapper packages [11:39:31] just release 1 new package, esprima-es5 [11:39:46] we're going to need at least another 2 months of experimenting before anybody can seriously recommend 2-phase parsing [11:39:46] ikarienator: but we need to try [11:39:49] for es7 that is [11:40:21] for es5 we can agree that it's time to release a new package, and *if* we do language flags, it'll be because they're straightforward and performant [11:40:57] to add to michaelficarra’s point, it’s only safe to do flags after all early errors are known and tested [11:41:13] otherwise, we might regress easily and walk back again for something that we promise [11:41:18] right, which is why for es6 vs. es5, it's a quagmire discussion [11:41:27] has bared no fruit for us for 5 meetings :-) [11:41:29] 2 months to decide if a second-pass traversal that asserts on unexpected things will do what it sounds like it will do? [11:41:37] with es7, we have a bit of time for this to marinate [11:41:41] http://www.merriam-webster.com/dictionary/quagmire [11:41:46] for ikarienator and my benefit :-) [11:42:00] the Iraq war is a quagmire [11:42:11] "getting stuck in the mud" [11:42:14] "going nowhere" [11:42:18] I’m all for it [11:42:26] Whoa, English has so many words for same things. [11:42:27] war? [11:42:40] Just want to hear from nzakas1 here [11:42:43] though I still personally investigate and evaluate lang/feature flags in the style of espree and acorn [11:42:52] because he is good sounding board for downstream projects [11:43:13] quagmires are bad [11:43:23] nzakas1: LOL [11:43:32] I've following the conversation, just not sure where to chime in [11:43:47] I meant, if we release esprima-es5, seems like that solves the eslint case of "user wants to specify es5 only [11:43:59] just means you have another dep [11:44:09] only if we also remove the non-ES5 pieces (like let and const) [11:44:17] nzakas1: yes, I want that too [11:44:18] but eslint parser is already configurable [11:44:30] The goal is to remove the eslint parser [11:44:35] and make espree a real fork [11:44:40] right [11:44:47] espree exists because of feature flags at this point [11:44:57] what I mean is the choice of parser can be specified at run-time for eslint [11:44:59] all other sticking points have been removed [11:45:07] ariya, that is true [11:45:15] but it needs to be esprima-like [11:45:20] same with JSCS [11:45:21] es5linter is eslint + es5 parser [11:45:28] to refresh [11:45:33] the long-term goal is to not have Espree [11:45:38] THIS ^ [11:45:50] for that to happen, we need to be able to specify language features [11:46:00] if we can get a pure ES5 Esprima parser, then that solves the baseline problem [11:46:10] let and const are fair to remove [11:46:13] now that we have 2.x [11:46:18] and then the next step is to deal with the ES6 pieces [11:46:27] so the ES5 parser is the first incremental step towards that goal [11:46:27] will probably call it 1.3, since it can’t be in patch version bump [11:46:46] ariya, no, it's called esprima-es5 1.0 [11:47:00] it's a separate package :-) [11:47:23] logistics :-) [11:47:29] are we going to return to the MetaProperty discussion? [11:47:36] michaelficarra: yes in a moment [11:47:43] 2015 goals have been defeerred twice :-\ [11:47:49] so language choice as a goal for 2015? [11:47:57] just wondering [11:48:06] nzakas1: the es6 pieces was only stop gap for dealing with potential implementation bugs in es6 [11:48:08] (regardless what the implementation is and how it will evolve behind the scene) [11:48:23] if we have es5 vs. es6 that seems to sovle it until es7 and jsx [11:48:33] surething [11:48:34] yes, language choice [11:48:38] yup [11:48:38] JSX is a fair addition to 3.0 [11:48:41] jeffmo: ^^^ [11:49:33] to sum up: the goal is full es6 support, releasing esprima-es5, and esprima 3.0 by June 1 [11:49:52] by end of year, we need a solution for JSX as plugin at worst, JSX in core at best [11:49:55] let me give some though on that esprima-es5 (as the name, not concept) [11:50:02] sure, ariya [11:50:21] es5prima [11:50:25] LOL [11:50:25] just because :) [11:50:27] YES [11:50:27] ariya: did discussion on feature flags change (i.e. for toggling JSX parsing) ? or do you mean just out of the box? [11:50:56] Ah, I missed mikesherov’s last comment on JSX [11:51:17] jeffmo: even better, if we know what hooks to be exposed so that it can be e.g. a plugin [11:51:29] ariya: got it [11:51:29] jeffmo: 3 options for JSX: core behind language flag, core out of the box, as a plguin (which infers externalizing sub parse functions) [11:51:38] yep [11:51:38] but goal is still the same [11:51:45] make esprima-fb not have to be full fork [11:51:53] just plugin maintainence [11:52:07] OK, any other goals for 2015? [11:52:09] not related to 2015 feature goals, but should we strive for e.g. type annotating the source code? [11:52:19] mikesherov: +1 — esprima-fb + flow parser are a huge source of work for me right now. Part of the reason I’ve found it hard to spend time on esprima-master too [11:52:24] I can easily see Flow or TypeScript to be useful here [11:52:32] ariya, sure. [11:52:44] OK, anyone else with 2015 goals? [11:53:02] * ariya doesn’t have more ideas [11:53:05] This of course assumes ESTree work is completed as well. [11:53:12] I have one more idea, implement a CST [11:53:20] but don't want to gaurantee that as a goal for us [11:53:22] it's a thought [11:53:38] still unsure of the value of a CST, personally [11:53:51] it’s almost like an entirely different project [11:53:57] yes [11:54:11] we should encourage a fork [11:54:13] I’d be far more interested in solving the needs for a CST in creative ways within esprima and/or ESTree [11:54:28] well, the reason is to enable a pipeline [11:54:34] just fork esprima, augment it with CST, and then it’s easy to see the value/diff [11:54:36] we can defer this discussion for later [11:54:41] but if everyone wants speed [11:54:55] Having to switch between completely different data structures for different static analysis is pretty unfortunate, and I’m not sure I’m convinced that AST and CST aren’t just abstract concepts [11:55:07] anyway, defering discussion is fine with me [11:55:12] all linters / transpilers / formatters should be able to accept a *lossless* tree as input and spit one out as output [11:55:20] yep, I agree [11:55:20] +1 for deferring [11:55:27] Let's defer [11:55:36] MetaProperty, let's squeeze in [11:55:37] michaelficarra: [11:56:28] JFYI, I have no data point to pick a side on MetaProperty [11:56:29] https://github.com/estree/estree/pull/32 [11:56:43] If we don't care strongly, let's defer to consensus [11:56:43] * ariya now has an excuse to read the spec again [11:56:46] awesome [11:56:47] but michaelficarra might care [11:56:52] I do [11:56:59] michaelficarra: ALWAYS CARES :-) [11:57:14] michaelficares [11:57:16] glad to have you there catching my bumbles [11:57:27] I propose `interface MetaProperty <: Expression { type: "MetaProperty"; kind: "new.target"; }` [11:57:46] and anyone disagreed? [11:57:57] kyle simpson [11:58:25] did any implementors disagree? [11:58:34] where is sebmck and rreverser stand? [11:58:35] his reasoning is that it may hurt concrete syntax representation in the future [11:58:49] yes, he is always concerned with that isn't he [11:58:55] that seems like phantom concern [11:58:58] his proposal was to represent the "new" and "target" parts separately [11:59:09] -1 on that for me [11:59:18] agreed that it's not a concern we can consider at this point with no working CST proposal [11:59:39] My CST proposal is additive to the tree anyway [11:59:45] nothing is locked in *anyway* [12:00:14] Anyone have opinions here, or should we just support Michael's position? [12:00:17] michaelficarra: you had earlier proposed "object" and "property" [12:00:21] just curious why now "kind"? [12:00:43] * ariya is fine with MetaProperty as proposed above [12:01:15] I just tested and acorn-babel (as the one on npm) doesn't support new.target [12:01:16] “…since the components of a meta property aren't individually meaningful.” [12:01:18] ah, position of the `.` will be lost [12:01:18] my comment from the issue: "I don't see a reason to split them on . since the components of a meta property aren't individually meaningful." [12:01:36] ariya beat me to it [12:01:47] michaelficarra: as usual :-) [12:01:47] MetaProperty makes sense to me (over MembExpr) [12:01:49] ah, so always collapse [12:02:46] What would be the downsides of having individual nodes for each of these metapropertis as well? [12:02:46] hmm [12:02:51] NewTarget [12:02:57] well I wouldn't colour it as "collapsing" [12:03:12] it's just an indicator of which MetaProperty it is [12:03:31] jeffmo: that would work as well, but is not really consistent with the rest of the SpiderMonkey spec [12:03:31] well, if I see the position of `new.target` is at multiline, I must guess where the newline actually is [12:03:51] but that's back to your point of meaningless *anyway [12:03:55] anyway* [12:04:01] michaelficarra: where else? I’m thinking of ThisExperssion and the Super refs as an example where it seems simliar [12:04:36] mikesherov: can you have a newline between ‘new’, ‘.’, and ‘target’ ? [12:04:39] and Literal and VariableDeclaration where it is not [12:04:41] I suppose so [12:04:45] jefmo: ^ [12:04:46] jeffmo: yes [12:05:14] Ah, in that case I’d be in favor of something that makes it at least possible to extend the node in the future such that positional information can be pulled out [12:05:30] kind = “target” seems mostly friendly to that [12:05:43] allows inclusion of location info for “target" [12:05:54] but this seems like a spectre [12:05:57] but keeps the outer node singular in that it wraps the inner [12:06:05] jeffmo: you mean positional info for each component of the MetaProperty? [12:06:16] I think ultimately, we're considering an extreme edgecase of a sociopath [12:06:22] michaelficarra: yes, given that ‘new’, ‘.’, and ‘target’ can sit separated syntactically [12:06:24] writing: [12:06:25] new. [12:06:28] target [12:06:31] like a crazy person [12:06:46] you know as well as I do such people exist :) [12:06:52] mikesherov: meh, all styles are crazy if you ask the right person :) [12:06:57] Yes [12:07:25] Additive [12:07:33] so we can start with michaelficarra 's proposal [12:07:42] and if crazy lunatic needs position info so bad [12:07:50] Anyway, I agree with the notion of not overloading member expression, and I like a MetaProperty node — but I do think it would be very practically useful to have ‘target’ sit as, at least, a sub-node of MetaProperty if only for purposes of location tracking [12:08:10] the MetaProperty can additively get additional properties to convey the necessary info for crazypants [12:08:12] I'm not saying it won't happen, but we can make a less-than-optimal-but-still-okay representation of position information for those crazy people [12:08:14] like the nested MemberExpression (object)? [12:08:26] ariya: yes [12:08:31] I gotta run, but +1 to jeffmo's comment [12:08:33] but immediately distinguishable from it [12:08:59] jeffmo: because it's additive, we can add it later when needed [12:09:26] mikesherov: it’s medium-additive if kind is a string [12:09:33] (means a breaking change later) [12:09:40] we can keep kind [12:09:47] mikesherov: JCSC will need that loc information [12:09:56] e.g. when disallowing spaces between object and property [12:09:59] ariya, it most certainly will [12:10:05] but JSCS is using the token list for that [12:10:12] I’m not saying getting rid of kind — that’s fine. Just that it should probably be a full-on sub-node rather than just a string [12:10:15] we use AST to get kinds of structures to look at [12:10:24] and then go to linked tokens to get concrete info [12:10:25] michaelficarra: so going back to object+property? [12:10:32] it's where my proposal for CST comes from :-) [12:11:04] mikesherov: *sigh* I have so much to say on the CST topic, but want to stay true to our commitment to defer :) [12:11:07] jeffmo: I was saying keep kind a string, and add separate nodes later that represent the component pieces [12:11:23] mikesherov: that seems pretty different from how location info works anywhere else though [12:11:38] mikesherov: but JSCS will need it right away, why adding it later? [12:11:43] mikesherov: what’s the downside of a sub-node? [12:11:49] JSCS will have it on day 1 :-) [12:12:03] Are we sure that there will be no additional things added to the MetaProperty in the future when new meta properties are introduced? [12:12:06] because it will know that Metaproperty has a firstToken of "new" [12:12:12] and lastToken of "target" [12:12:16] I only have a problem with object+property because it's *not* a member access, it is only syntactically similar to one [12:12:17] with punctuator in the middle [12:12:22] If we are not sure about that, we should use a new node NewTarget instead. [12:12:29] it doesn't give a shit about position info in the AST portion :-) [12:12:38] That will be the least breakable definition. [12:12:54] ikarienator: there almost certainly will be new things other than just ‘target' [12:12:59] michaelficarra: sure, it doesn’t have to that name [12:13:11] We can define an super class MetaProperty and NewTarget <: MetaProperty [12:13:28] all metproperties will *look* like a memberExpression, yes? [12:13:41] I gotta run, will catch up later [12:13:44] thanks folks! [12:13:48] I have tog o too [12:13:49] ikarienator: only problem there is that we don’t have a good place to distinguish location info for ‘new’ vs ‘target’ (which can have whitespace between them) [12:13:51] thanks ariya [12:13:58] Then we can use type to determine which is which and, the last but not least, we don't need to bike shed about the naming in kind. [12:14:14] right, naming bikeshed and type are least of concern [12:14:19] both just bikesheds [12:14:21] ikarienator: I don’t care if we call it ‘kind’ relaly — just what the type of that node-property is [12:14:33] actually question is around single "kind" field that is lossier than necessary [12:14:38]