Type Argument Lists grammar is ambiguous #1121

Activity

1. danquirk commented on Nov 11, 2014

   

   Dan Quirk (danquirk)

   on Nov 11, 2014

   Member

   More actions

   This is covered in 4.12.3 in the spec:

   The inclusion of type arguments in the Arguments production (section 4.12) gives rise to certain ambiguities in the grammar for expressions. For example, the statement

   f(g<A, B>(7));

   could be interpreted as a call to 'f' with two arguments, 'g < A' and 'B > (7)'. Alternatively, it could be interpreted as a call to 'f' with one argument, which is a call to a generic function 'g' with two type arguments and one regular argument.
   The grammar ambiguity is resolved as follows: In a context where one possible interpretation of a sequence of tokens is an Arguments production, if the initial sequence of tokens forms a syntactically correct TypeArguments production and is followed by a '(' token, then the sequence of tokens is processed an Arguments production, and any other possible interpretation is discarded. Otherwise, the sequence of tokens is not considered an Arguments production.
   This rule means that the call to 'f' above is interpreted as a call with one argument, which is a call to a generic function 'g' with two type arguments and one regular argument. However, the statements

   f(g < A, B > 7);
   f(g < A, B > +(7));

   are both interpreted as calls to 'f' with two arguments.
2. Dan Quirk (danquirk)

   closed this as completedon Nov 11, 2014
3. Dan Quirk (danquirk)

   added

   By DesignDeprecated - use "Working as Intended" or "Design Limitation" insteadDeprecated - use "Working as Intended" or "Design Limitation" instead

   on Nov 11, 2014
4. arv commented on Nov 11, 2014

   

   Erik Arvidsson (arv)

   on Nov 11, 2014

   Author

   More actions

   I'm concerned that we will not be able to spec this since backtracking is explicitly not allowed in the Ecma 262 grammar. I assume you discussed this to death already...
5. danquirk commented on Nov 11, 2014

   

   Dan Quirk (danquirk)

   on Nov 11, 2014

   Member

   More actions

   Cyrus Najmabadi (@CyrusNajmabadi) is probably a good person to chime in on this in detail
6. CyrusNajmabadi commented on Nov 11, 2014

   

   Cyrus Najmabadi (CyrusNajmabadi)

   on Nov 11, 2014

   Contributor

   More actions

   Erik Arvidsson (@arv) Currently TypeScript uses backtracking to implement the above rule that daniel listed. However, i'm theorizing it would also be possible to create some sort of cover grammar for this situation to deal with the ambiguity and lookahead. i.e. something similar to how ES6 handles things when it sees: (a,b,c ... x,y,z) and doesn't know at that point if it has an arrow function or parenthesized comma expression.

   As to what ES allows/disallows, i'm not sure that's relevant for us. ES specifies the rules for their grammar productions, but makes no statements (for or against) languages which are a superset of them. So whatever they've decided for their grammar rules doesn't really apply to ours :)
7. arv commented on Nov 11, 2014

   

   Erik Arvidsson (arv)

   on Nov 11, 2014

   Author

   More actions

   I agree. TypeScript does not need to play by the same rules.

   Let me just explain where I'm coming from. I'm a member of TC39 and I work at Google. I'm involved in Traceur, AtScript (Angulars take on TypeScript) and V8.

   One of my goals is to try to standardize something in this space in the coming years.
8. CyrusNajmabadi commented on Nov 11, 2014

   

   Cyrus Najmabadi (CyrusNajmabadi)

   on Nov 11, 2014

   Contributor

   More actions

   Erik Arvidsson (@arv) That sounds great. Is there anything we can do to help?
9. microsoft

   locked and limited conversation to collaborators on Jun 18, 2018