Challenge 1: Attempting to Rebind x at the Top Level of GHCi — Possible Solution
====================================================================

GHCi session:

    Prelude> let x = 10
    Prelude> x
    10
    Prelude> let x = 20
    Prelude> x
    20

-- This LOOKS like reassignment happened -- x reported 10, then later
-- reported 20 -- but GHCi's top-level `let` bindings are actually a
-- special, session-only case: each `let x = ...` line at the GHCi
-- prompt creates a genuinely NEW top-level binding that shadows the
-- previous one, exactly the same shadowing mechanism the chapter
-- describes for nested let...in expressions, just happening one
-- prompt line at a time instead of within a single expression's
-- scope. The original x = 10 binding isn't mutated or destroyed --
-- it's simply no longer the binding that the name `x` refers to
-- going forward in this session.
--
-- This is a genuine special convenience GHCi offers specifically to
-- make interactive experimentation less awkward -- it does NOT mean
-- ordinary Haskell code (inside a real .hs file, in a single
-- expression's scope) can reassign a binding the same way. Inside a
-- single `let x = 10 in ...` expression, there is no equivalent
-- second top-level prompt to shadow from -- attempting `x = 20` a
-- second time within that same expression's scope would just be a
-- duplicate binding error, not a working rebind.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly identifies GHCi's top-level let as a special
interactive-session shadowing convenience rather than genuine
reassignment, and distinguishes it clearly from what would actually
happen inside a single expression's own scope, matching the chapter's
own distinction between shadowing and mutation.