RE: Higher-order function application

[Andrew Kennedy]

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
> 
>