I'm comfortable either way, but I tend to agree with Geoffrey. IMO, the commas would hinder readability when compared with explicitly bracketed applications. In Haskell, I would tend towards f a (g b) even when it wasn't a requirement to be explicit. It being required only in the case when f takes 3 or more arguments.
In addition, taking the statistical approach with hassle in general usage; I would guess that one would have to bracket app_exprs less than they would have to comma exprs. But I guess that would depend on style. On Wed, Mar 11, 2009 at 2:56 PM, Geoffrey Irving <[email protected]> wrote: > On Wed, Mar 11, 2009 at 2:48 PM, Jonathan S. Shapiro <[email protected]> > wrote: > > 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? > > I'm in favor of the separate app_expr nonterminal. I believe I had to > do that when parsing ocaml as well, since even in a fully curried > language "a b c" can be parsed as either "(a b) c" or "a (b c)" if > there's only one expr nonterminal. > > I also think that app_expr can be used *everywhere* except as for the > arguments of a function. E.g., > > f a + f b > > should work as well. > > Geoffrey > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev > -- We can't solve problems by using the same kind of thinking we used when we created them. - A. Einstein
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
