There is no class Function built into Haskell; if there were, one could define subclasses of it, e.g. a subclass of invertible functions. It is possible to define the class, to make -> an instance of it and to make ($) as in f$x (but not the usual ``invisible'' application operator as in f x) work with it, e.g. ...

import Prelude hiding(($)) --NB. $ (re)defined below.

class Function fnType where
  ($)   :: (fnType t u) -> t -> u
  apply :: (fnType t u) -> t -> u

  f $ x = apply f x

instance Function (->) where
  apply f x = f x

class (Function fnType) => Invertible fnType where
  inverse :: fnType t u -> fnType u t

data IArrow t u = IFN (t->u) (u->t)

instance Function   IArrow where
  apply (IFN f i) x = f x

instance Invertible IArrow where
  inverse (IFN f i) = IFN i f

successor   = IFN (\x->x+1) (\x->x-1)
-- e.g. an Invertible Function
predecessor = inverse successor

... successor $ 7 ... etc.

Also see class Pair.

Message: 4
Date: Tue, 29 Oct 2002 10:54:30 +1100 (EST)
From: Lloyd Allison ... 
To: haskell at haskell dot org  (under Oct 2002 on haskell_list)
Subject: class Function ?

... I would like to have a ``class Function'' which has the operators ``$'',  ``.'',  etc. and most particularly ``'', so that one can define sub-classes of Function (e.g. functions having inverses, say) that can still be applied in the usual way, i.e. ``f x''. ...

Message: 7
Date: Tue, 29 Oct 2002 07:41:31 +0100
From: Nick Name  ...
Subject: Re: class Function ?

... The only thing that should be done is to invent a special name for the juxtaposition operator (or just to use $), and to let (->) become an instance of the "Function" class.
I'd also like this, because it would enable stuff like associative maps used as functions.
-- Vincenzo

Message: 9
Date: Tue, 29 Oct 2002 00:10:09 -0800
From: Ashley Yakeley  ...

... I think function application has to be primitive and not an operator. Otherwise you would end up with this:
f a   is syntactic sugar for
f `juxtapose` a   is syntactic sugar for
(juxtapose f) a   is syntactic sugar for
(juxtapose ((juxtapose juxtapose) f)) a   ... etc. ...

Message: 10
Date: Tue, 29 Oct 2002 09:34:03 +0100 (MET)
From: Josef Svenningsson ...   

... Overloading "blank space" or function application has been one of my favourite haskell jokes for some time. While I have many times thought that it would be really cute I think that in practice it would be just unmanagable. Every function composition would be overloaded and we would end up with tons of class constraints like
Function a => (a b c) -> b -> c
It would be slow and the types would be unreadable.

> When presenting definitions in Haskell (to myself, or to students),
> I don't like being forced to decide on the representation of functions
> (be it `actual function', array, list, FiniteMap, whatever) too early.
I think this is a non-argument. A good programming style (at least in my opinion) is to always assume `actual functions' as the representation. You can always convert bulk type operations later.
An example. Say you have a function foo which takes a map as its first argument. Just assume the `actual function' respresentation. When a function bar uses foo but has a different representation of map we just cast it to a function. ...
[e.g.] foo :: (key -> value) -> ....
bar = ... foo (\key -> lookup map key) ...

Message: 4
Date: Tue, 29 Oct 2002 11:42:04 +0000
From: Jon Fairbairn  ...

... we could just make $ the primitive instead of juxtaposition (and infix the primary form).
Then   f a   is shorthand for   f $ a   and it stops there. ...

Message: 8
Date: Tue, 29 Oct 2002 16:57:17 +0000
From: Jon Fairbairn ...

... The class Function and it's first instance would have to be built in (not too onerous since function application is anyway). Not that I'm necessarily in favour of this, you understand.

On the subject of classes and names, also note:

Subject: Prelude
Date: Fri, 24 Oct 2003 01:47:34 -0700  (haskell_list)
From: Per Larsson

... In the prelude, a lot of efforts have been made to overload arithmetic names and operators for numerical classes. I think it is a pity that the prelude is considerably more careless with other "good" names which, in my opinion, should have been included in type classes.
&&, ||, (not):  These could have been included in a Boolean (ComplementedBoolean) class and reused for other boolean algebras than the Bool data type, e.g. in library Data.Bits, library Data.Set, lifted for monads or simply being available for user defined types e.g. representing logical formulae or parser combinators. ...
... ++, concat ... map ... null, elem, filter, reverse ... and, or, any, all ...

And . . .

Subject: Re: Why are strings linked lists?
Date: Thu, 27 Nov 2003 23:49:56 -0800  (haskell_list)
From: John Meacham

... Something I'd like to see (perhaps a bit less drastic) would be a String class, similar to Num so string constants would have type String a => a then we can make [Char], PackedString, and whatnot instances. It should at least make working with alternate string representations easier.