Something like this was proposed by Satish Thatte a while back; he called it "implicit scaling". See S. Thatte. A type system for implicit scaling. Science of computer programming, 17:217--245, 1991. S. Thatte. Type inference and implicit scaling. In European Symposium on Programming. Springer Verlag LNCS 432, 1990. Unfortunately neither appear to be available online. - Andrew. > -----Original Message----- > From: Tim Sweeney [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, August 23, 2000 7:37 AM > To: [EMAIL PROTECTED] > Subject: Higher-order function application > > > In Haskell, only a single notion of "function application" > exists, where a > function f::t->u is passed a parameter of type t, returning a > result of type > u. Example function calls are: > > 1+2 > sin 3.14 > map sin [1:2:3] > > However, a higher-order notion of function application seems > sensible in > many cases. For example, consider the following expressions, > which Haskell > rejects, despite an "obvious" programmer intent: > > cos+sin -- intent: \x->((cos x)+(sin x)) > cos(sin) -- intent: \x->cos(sin(x)) > (cos,sin)(1,2) -- intent: cos(1),sin(2) > (+)(1,2) -- intent: (+)(1)(2) > cos [1:2:3] -- intent: map cos [1:2:3] > > From this intuition, let's postulate that it's possible for a > compiler to > automatically accept such expressions by translating them to the more > verbose "intent" listed above, using rules such as: > > 1. Operator calls like (+) over functions translate to lambda > abstractions > as in the "cos+sin" example. > > 2. A pair of functions f::t->u, g::v->w acts as a single > function from pairs > to pairs, (f,g)::(t,u)->(v,w). > > 3. Translating function calling into function composition, > like "cos(sin)". > > 4. Automatic currying when a pair is passed to a curried function. > > 5. Automatic uncurrying when a function expecting a parameter > of type (t,u) > is passed a single value of type t. > > 6. Applying a function f:t->u to a list x::[t] translates to > "map f x". > > I wonder, are these rules self-consistent? Are they > unambiguous in all > cases? Are there other rules we can safely add? > > It also seems that every statement above is simply a new > axiom at the type > checker's disposal. For example, to describe the general notion of > "cos+sin" meaning "\x->(cos(x)+sin(x))", we say: > > for all types t,u,v, > for all functions f,g :: t->u, > for all functions h ::u->u->v, > h (f,g) = \x->h(f(x),g(x)). > > Is this "higher order function application" a useful notion, > and does any > research exist on the topic? > > -Tim > >

- Higher-order function application Tim Sweeney
- Re: Higher-order function application Adrian Hey
- Re: Higher-order function application George Russell
- Re: Higher-order function application Ch. A. Herrmann
- Re: Higher-order function application Andreas Rossberg
- Re: Higher-order function application D. Tweed

- Re: Higher-order function application Andrew Kennedy
- Re: Higher-order function application Bjorn Lisper
- Re: Higher-order function application Ralf Muschall
- Re: Higher-order function application William Lee Irwin III