To me, (f x y) and ((f x) y) are the same thing, in both cases f :: a -> b -> c where the types of a, b, and c are inferred.
Keean. On 12 Feb 2015 08:27, "Matt Oliveri" <[email protected]> wrote: > 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 >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
