Challenge 3: Why Functor's f Must Be a Type Constructor — Possible Solution
====================================================================

-- fmap's own type signature is:
--     fmap :: (a -> b) -> f a -> f b
--
-- Look closely at how f is actually USED in this signature: it never
-- appears on its own, standing alone as a complete type. It always
-- appears immediately applied to another type variable -- as `f a` in
-- the second argument, and as `f b` in the result. This is exactly
-- the syntax for applying a type constructor to a type argument, the
-- same shape as writing `Maybe Int` (Maybe applied to Int) or
-- `Tree a` (Tree applied to a) from haskell1-6's own material.
--
-- If f were a concrete, ordinary type -- like Int or Bool -- then
-- `f a` would be meaningless: you cannot apply "Int" to another type
-- the way you apply Maybe to Int, because Int isn't a function from
-- types to types, it's already a finished, complete type on its own.
-- Only something that ITSELF still needs one more type argument
-- before it becomes a real type -- a type constructor like Maybe,
-- [], or Tree -- can sensibly appear in the `f a` / `f b` positions
-- fmap's signature requires.
--
-- So the requirement that f be a type constructor isn't an arbitrary
-- rule bolted onto Functor -- it falls directly out of what fmap's own
-- type signature demands: something capable of being applied to a
-- type argument, twice, once for the "before" type (a) and once for
-- the "after" type (b).

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly traces the type-constructor requirement directly back
to how f is actually used inside fmap's own signature (always applied
to another type, never standing alone), rather than treating it as an
arbitrary rule, matching the chapter's own explanation.