I'm pretty sure this is how it's done in Haskell, although there certainly are cases where things must be wrapped in (), but those are only where you are concerned about the order in which arguments are applied. (one could also use the ($) operator) i.e. pow4 x = mul mul x x mul x x
This is should be unable to be evaluated, since we don't want the 1st mul to attempt to multiply the function mul with x . pow4 x = mul (mul x x) (mul x x) The . and $ operator would be a nice feature in this case: pow4' x = (mul x) . (mul x) . (mul x) $ x In any case, I'm not sure how it would be parsed, but Option 2 certainly seems to be almost a requisite for an auto-currying language (is BitC going to be auto-currying, correct?) On Fri, Mar 6, 2009 at 2:59 PM, Jonathan S. Shapiro <[email protected]>wrote: > On Fri, Mar 6, 2009 at 2:56 PM, Sandro Magi <[email protected]>wrote: > >> Jonathan S. Shapiro wrote: >> > The problem is that in things like >> > >> > f a b + f c d >> > >> > we do not know how many arguments to "consume" for f until f is typed, >> > and we don't have that information at parse time. This works in ML >> > *because* of curried forms. The parser builds: >> >> Can't you just consume until you hit an invalid name, ie. >> non-alphanumeric character? Assuming infix can be comprised only of >> symbols, like ML, while legal names are only alphanumeric. > > > Interesting. I had not known that rule. Yes. That does simplify things a > good bit. > > shap > > _______________________________________________ > 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
