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? _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
