Disallow prefixes and terms having the same name in a scope

[masak]

Something like H(50) could be either a prefix:<H> applied to a 50 (with superstitious parentheses), or a function call to a function H with one argument 50.

We kind of need to choose already at parse time, and the choice should be independent of the lexical environment, whether we find H or prefix:<H> (or both) among our bound names.

Which kind of means it needs to parse as a function call, always. But should H (50) (with an extra space) also be the function call? On one hand, it could be a way to disambiguate; on the other, we've so far managed to make the language completely whitespace-insignificant in exactly this sense. (Unlike Perl 6.)

I'm inclined to make even H (50) parse as a function call, because I like the whitespace insignificance that much. The question is how much we cater to someone who wanted it to mean the prefix, and what to give them instead.

I guess the most extreme thing to do would be to forbid the name clash in the first place, just like between infixes and postfixes.

[masak]

Having slept on it, I'm slightly more leaning towards never allowing the conflict in the first place. That is, H(50) gets to mean either, but it's always clear from the lexical environment which one it is.

[masak]

In the end, that's not so different from how +++ could be any number of combinations of postfixes, infix, and prefixes, according to the lexical environment. (All within the bounds of LTM and ratcheting.)

[masak]

I think "parentheses after a term means function call" is a reasonable-enough rule to turn into an inviolable rule. But (stepping back a bit), the original problem is that parentheses are both terms (for grouping) and postcircumfixes (for function/macro invocation).

Come to think of it, same thing could happen with a [b], with a and [b] being either a prefix op and an array literal or a term and a postfix lookup.