actually, I was confused below. in the case of f a g b f a (g b) is required, or f a $ g b where $ is the death-to-parens infix operator, which has a precedence of 0.
On Wed, Mar 11, 2009 at 3:07 PM, Rick R <[email protected]> wrote: > 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 > -- 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
