Challenge 3: Why the Curried Structure Enables Automatic Partial Application — Possible Solution
====================================================================

-- Int -> Int -> Int is really Int -> (Int -> Int) because -> is
-- right-associative in Haskell's type syntax -- the arrows aren't
-- read as separators in a flat list of "two inputs, one output";
-- each arrow marks a genuine, individual function boundary. Reading
-- the type strictly left to right and grouping from the right gives:
-- a function that accepts ONE Int, and returns, as its result, a
-- SECOND function of type Int -> Int (which itself accepts one Int
-- and returns the final Int).
--
-- This structure is exactly what makes automatic partial application
-- possible for every function, with no special-casing required
-- anywhere: applying a curried function to just its first argument
-- is not a "partial" or incomplete operation in any special sense --
-- it's simply ORDINARY function application, run once. The thing
-- that gets returned is, by the type's own definition, just another
-- real function value like any other, which can be stored in a
-- variable, passed around, or applied again later. There's no
-- separate "partial application feature" bolted on top of normal
-- function calls -- partial application and full application are
-- literally the same mechanism, just stopped at different points
-- along the same curried chain.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly explains right-associativity as the reason the type
decomposes into nested one-argument functions, and correctly
identifies that partial application isn't a separate feature but
simply ordinary function application applied to a curried chain --
matching the chapter's own central explanation.