On Wed, Feb 11, 2015 at 11:13 PM, Matt Oliveri <[email protected]> wrote:
> I like Option 1. Arguably, "curried" arguments that are required to be > passed at once are not really curried arguments.... That may be, but we're definitely not going to adopt lazy evaluation. > Alternatively, we could adopt a comma convention (parens in types for > > emphasis): > > > > def f x y = x + y // fn 1 'a -> (fn 1 'a -> 'a) > > def f x, y = x + y // fn 2 'a -> 'a -> 'a > > def f x, y z = x + y + z // fn 2 'a -> 'a -> (fn 1 'a -> 'a) > What about--following the idea that these are Lispy functions--using > lambda to get true currying? > def f x y = x + y // fn 2 'a -> 'a -> 'a > def f x = lambda y = x + y // fn 1 'a -> (fn 1 'a -> 'a) What I wrote is just a convenience syntax for what you wrote. Except for the small difference that functions in a 'def' context are introduced in a letrec so that they can be recursive. > INFERENCE > > > > What arity should we infer for f: > > > > def myfn f x y = > > let u = f x y > > v = f x > > in > > v y > > > > I think the inferred arity here is "1". > To complete my import of Lispy functions: > (f x y) // f needs to be arity 2 > ((f x) y) // f needs to be arity 1 (and its result too) In LISP that would make sense. But a curried application syntax does not mean that we are doing one-arg-at-a-time application. If we cannot reasonably infer arity in this kind of syntax, it won't work very well for us. I think it's worth a try, and I plan to try it, but if we can't make it work we will have to remove it. I'm an old LISP hacker. I want *all* the parens to be optional. :-) shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
