[bitc-dev] Application of curry generates some heat

[Jonathan S. Shapiro]

Sorry. Couldn't resist that subject line.

Okay. It's emerging that n-ary functions and curried-style application
syntax do not get along. It impacts both type declarations and
function application. The issue is that given:

  f1 a f2 . b

the parser can't figure out whether this is (f1 a (f2 b)) or (f1 a f2
b). This cannot be resolved with associativity rules in most parsers,
because most parser generators only have a notion of associativity for
tokens.  It's easy in C because the commas in the function call syntax
have the effect of "bracketing" the nested expressions, and I think we
are going to need to do something here.

While we could adopt C-style syntax, another option to consider is
that function applications should only be permitted in bracketed
contexts. That is: we have separate nonterminals for expr and
app_expr, and only use app_expr in contexts that are surrounded by
tokens.

The effect of this is that:

   f1 a f2 b

is unambiguously passing f2 as a value, because the inner application
syntactically requires parentheses or some such:

  f1 a (f2 b)

For the most part, the only place that this will crop up in the face
of the programmer is applications nested within applications. It
should't show up for infix/outfix operators (we can handle those with
precedence rules). But it *will* show up in nested type specification.

I tentatively prefer this to introducing a comma syntax here. It feels
more readable to me.

Reactions/opinions?