Not sure why you need arity inference, type inference I have done works fine without it. Any given function name generally has the same arity in all versions, so you know the required arity from the function definitions. You don't need the arity during type inference.
Keean. On 12 Feb 2015 07:13, "Matt Oliveri" <[email protected]> wrote: > 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 >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
