Let parsing be scope dependent

[lrhn]

As a consequence of this, code such as g(x < y, z > (3 + 4)) which currently parses as an application of g to two arguments will be reinterpreted in a breaking fashion, and will need to be re-parenthesized to be valid (e.g. as g((x < y), z > (3 + 4))).

Another option, which requires more from the parser, is to allow parsing to depend on whether, e.g., z above is a type name or not. Since Type objects won't have a > operator, there is no existing functioning code where z is a type.

It does require the parser to delay final judgement on the expression/expression list parsing until it has resolved identifiers, but it might be possible.

Making a breaking change is also possible.

[leafpetersen]

I don't object to this per se. I don't think it would be terrible for the platforms (which have to do resolution eventually anyway), though probably annoying to have argument lists in a limbo state until resolution. I wonder if we might have some use cases in which folks want to parse without resolving though - maybe in transformers?

[munificent]

I wonder if we might have some use cases in which folks want to parse without resolving though - maybe in transformers?

Yes, we definitely do. For example, the formatter doesn't resolve and really doesn't want to to keep performance good. At the same time, the formatter definitely does need to distinguish between a generic method and a series of comparisons here since they are formatted differently.

Personally, I'd rather keep the grammar context free and just pick a disambiguation rule. I think the generic method case will be much more common, so I'd just parse it as that.

[jakemac53]

I wonder if we might have some use cases in which folks want to parse without resolving though -
maybe in transformers?

Afaik the current angular 2 transformer design relies heavily on parsing without resolving, @kegluneq would have more info on that.

[kegluneq]

+1 @jakemac53, that is the goal. We may choose to resolve when parsing isn't enough (e.g. to understand enough to generate useful error messages), but we'd like that to be the exception, not the rule.