On Wed, Feb 11, 2015 at 10:07 AM, Jonathan S. Shapiro <[email protected]> wrote: > TYPE COMPATIBILITY > > The question concerns type compatibility. In OCaml or Haskell, where > application is curried, the following two types are indistinguishable: > > fn 1 int -> int -> int > fn 2 int -> int -> int > > The question arises: what should the compatibility rules be in BitC? There > seem to be three possible choices: > > Option 1: Arity must match. This is the easiest choice, but it means (for > example) that we can't map over a list producing an output list of partially > applied functions without introducing an explicit lambda. It's the cleanest > choice for type inference purposes.
I like Option 1. Arguably, "curried" arguments that are required to be passed at once are not really curried arguments. And that's OK. Currying never seemed useful enough to me to justify worrying systems programmers about closure allocation. So you'd just have Lisp-style applications, where multiple (non-curried) arguments are separated by spaces. > FUNCTION DEFINITION SYNTAX > > Given that we can explicitly annotate to get any arity we want, two > questions now arise. > > First, what type should be given to the following function in the absence of > annotation? > > def f x y = x + y > > I propose that it should be fn 2 'a -> 'a -> 'a and not fn 1 'a -> 'a -> > 'a. You can get a different arity by using either: > > def f = lambda 1 x y = x + y > def f 1 x y = x + y > > Note that numbers aren't identifiers, which is why this works. Though I > concede they feel strange. > > 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) > INFERENCE > > One problem that I anticipate with curried application syntax is that it > removes information needed for arity inference. GIven: > > def myfn f x y = f x y > > what arity should we infer for f? In this case, I think the answer probably > turns out to be '2", but it's possible to imagine other cases in which that > would not be the case. For example: > > 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) I would appreciate it if the outermost parentheses are optional, as in non-Lisp applications. Also, you might want to consider a more Racket-style define: def (f x y) = x + y // fn 2 ... def ((f x) y) = x + y // fn 1 ... Again, the outermost parens could be optional, if that doesn't look too weird to you. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
