On Sun, Feb 8, 2015 at 3:25 PM, William ML Leslie < [email protected]> wrote:
> Alternatively, if we decide that '+' has higher precedence, we will parse >> as: >> >> (f1 a) + (f1 b) >> >> > Isn't that backwards somewhat? > if they have equal precedence, (((f1 a) +) f1) b). > if + has higher precedence, ((f1 (a + f1)) b). > if + has lower precedence, (f1 a) + (f1 b). Oops. Yes. Silly mistake on my part. Thank you. > My personal opinion is that this is a very confusing parse of >> >> f1 a + f1 b >> >> >> in a language that adopts currying, because the mental convention here is >> "things accumulate left to right". >> > > Are people regularly confused about how infix operators work in ML family > languages? > That's a very astute question, and the answer is: I don't know. A more important question, perhaps, is whether this would confuse C and C++ programmers. The answer to that, in my opinion, is unequivocally "yes". Another relevant bit of anecdote on this is the trend in parenthesization in C. There are a number of circumstances where C does not require parentheses but compilers in practice do. Assignments in conditionals come to mind. There are many more examples from individual coding standards, most of which exist to remove ambiguities as seen by the reader. So a possibly useful answer here is that this case is difficult enough to read that a coding guideline requirement for parenthesis seems mandatory. I don't have a strong opinion about the aesthetics of curried syntax one way or the other. Coming from C it's certainly less familiar. But the visual ambiguity inherent in the curried notation actually *does* strike me as a bad thing from the standpoint of writing robust programs. Yup. Parens in BitC are done in the mixfix engine! But this means that the >> following two expressions are structurally similar, differentiated only by >> precedence: >> >> f a + f b >> f a , f b >> >> >> It seems syntactically uncomfortable, but I don't really see any good way >> to eliminate the issue entirely unless we move these sorts of constructs >> back into the arena of "language predefined expressions". >> > > Sorry Shap - I just don't comprehend your discomfort here. > Well, since I got the precedence wrong in the first example, my discomfort didn't really make sense here. That would go some ways toward explaining why you don't comprehend it. :-) shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
