On Thu, Feb 12, 2015 at 9:55 AM, Jonathan S. Shapiro <[email protected]> wrote: > 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.
Huh? I didn't say lazy evaluation. I think one of us has totally misunderstood the other. >> > 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. Yeah, I know. The point was that Option 1 is essentially to distinguish multi-arg functions and curried functions, like Lisp. So my recommendation was to consider Lisp syntax. >> > 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 really walked into it this time. I don't know what you mean because I didn't carefully disambiguate curried-looking syntax from what I've meant by currying, which is just the trick of taking an extra argument by returning a function. In Lisp, (f x y) is not a curried application, and so in my version of Option 1, it wouldn't be either. It's a single application of 2 arguments to an arity 2 function. In another recent email, I called that a 2-application. A 2-application can be implemented as a single function call without any need for cleverness, since the arity is part of the type, as in Option 1. I figure with the Lisp application syntax, we can easily infer function arity because the syntax provides no leeway for how many arguments to apply to a function with a known arity. Oh right: I'm definitely not allowing Lisp-style variable arity functions. > 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. Like Option 1, I intended my proposal to be the dirt simple option. I'm really confused if it doesn't obviously work. Unless you mean that it might be too inconvenient for the programmer. But I kinda doubt that. > I'm an old LISP hacker. I want *all* the parens to be optional. :-) I've been looking into Lisps recently, and I saw your name on TinyScheme. Way to go! _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
