RFC: fix #18650, parsing generator expressions containing macro calls

[JeffBezanson]

Previously @mac x for i = ... always parsed as a macro call wrapping a for loop, except inside square brackets (giving a comprehension). Now it will parse as a generator when it occurs inside a function call argument list.

This is very lightly breaking, since (1) it's very unusual to write a for loop inside an argument list, (2) most (all?) forms of this either gave a syntax error before, or will give a syntax error after this change.

I'm a bit on the fence about this. The new parsing is more useful, but means that in f(<something>) vs. (<something>), the <something> can parse differently.

[ararslan]

The new parsing is more useful, but means that in f(<something>) vs. (<something>), the <something> can parse differently.

That seems weird and surprising to me. I'm not sure it would be beneficial to do that, especially because just using parentheses for macro calls inside of generator expressions is clearer anyway.

[JeffBezanson]

@StefanKarpinski What do you think?

[StefanKarpinski]

I think this is a better tradeoff. The sum(@m x for i = 1:n end) syntax is pretty strange and seems better to require parens for than the mean(@elapsed sleep(0.1) for _ = 1:0) syntax, which actually seems quite useful. If we ever wanted to support both we could have a parser with arbitrary backtracking .

[JeffBezanson]

Yeah, I think I agree. Either way you can always get what you want by adding enough parentheses, but this change makes the property "does what you want or else throws an error" hold in more cases.