> ... More seriously, in "f x", there is an explicit
> operator already.  It's "f".  The space is needed for lexical
> reasons only.  If you say no, functions are not operators --
> though in Haskell infix operators are functions -- but
> application is the operator, so you should write "f @ x" (usual
> FP notation) or "f.x" (Dijkstra), then although it isn't
> technically true, I've always felt that there is an infinite
> regress lurking in the background:
> if x + y means (+) x y
> which really stands for (+)@x @ y
> then shouldn't that in turn stand for (@)((@)(+)x)y
> and what should _that_ stand for?

Heh, heh there's another corner where Haskell semantics appears to give an infinite regress;

and we have to suppose there's some internal magic that can't be expressed in the surface language:

Report section 6.4.1 Numeric Literals. "An integer literal represents the application of the function `fromInteger` to the appropriate value of type `Integer`."

OK. How do we write in Haskell that "appropriate value"?

We could write `7 :: Integer` but that's shorthand for `(fromInteger #7#) :: Integer`, in which I've used `#7#` to denote the "appropriate value" doo-hickey. There's no way in Haskell to write a literal that's type `Integer`, except by invoking `fromInteger`.

`(fromInteger (7 :: Integer)) :: Integer` ? Both the explicit and implicit `fromInteger` in there are no-ops.

AntC