On Fri, Mar 6, 2009 at 10:41 AM, Jonathan S. Shapiro <[email protected]> wrote: > I need to preface this by saying that if something doesn't work in the > parser I won't use it. :-) > > We seem to have two broad options for procedure application: I'm not > entirely convinced that the second one works if we retain n-ary functions > and we decide to do mixfix: > > Option 1: > > proc-name( arg ... arg) > > Option 2: > > proc-name arg ... arg > > While I personally like Option 2, the problem that I anticipate is that > things like: > > f 1 + f 2 > > will tend to require parenthesization. Same number of parens as in option 1, > but placed differently: > > (f 1) + (f 2) > > I personally do not find this objectionable -- moving the parens to wrap the > call actually makes this a bit clearer for me.
I'm definitely in favor of Option 2, and don't understand why (f 1 + f 2) would require parentheses. Can you explain the problem in more detail? Most (all?) languages with curry style notation for function calls give application higher precedence than addition (including math, for example), so (f 1 + f 2) should be fine. The n-arity functions should be a problem if you're still planning to allow calling functions with more arguments than they require, since your grammar can parse them in curry style and convert to n-arity calls during semantic analysis. On the hand, in hindsight it seems like your extra arguments proposal breaks type inference, so that may not work. Geoffrey _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
