I'm not sure what you're saying we should infer for the (f x y) example. That could either be a 2-application, or two 1-applications, if they had the same syntax. That's why I proposed writing two 1-applications like ((f x) y).
On Thu, Feb 12, 2015 at 3:10 AM, Keean Schupke <[email protected]> wrote: > Its not a problem, in the case where you only pass in the function as an > argument, it must be completely applied, so you can infer its complete > (local polymorphic) type from its use. > > In the more complex case where you pass in a function, partially apply it, > and return the rest, you are okay if you have the whole program. > > I think types should be specified at module boundaries in any case, as you > want a stable interface, not type inference. A module should be a smaller > unit than a file, so that you can have more than one module in a file, but > not more than one file in a module. In this way you can infer all the types > in a module without having the whole program. > > Keean. > > On 12 Feb 2015 07:53, "Matt Oliveri" <[email protected]> wrote: >> >> But if you get a parameter called f, and you do (f x y), what arity is >> f? If applying functions of different arities had the same syntax, you >> wouldn't know. But you want to know if arity mismatch is a type error. >> >> On Thu, Feb 12, 2015 at 2:31 AM, Keean Schupke <[email protected]> wrote: >> > 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. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
