Exercise 2: Does Unary Minus Leak a Raw Python Error? — Possible Solution
====================================================================

THE RELEVANT CODE (unchanged from the chapter)
------------------------------
    def visit_unary(self, node):
        val = node.right.accept(self)
        if node.operator == '-':
            if not isinstance(val, float):
                raise WispRuntimeError(
                    "operand of unary '-' must be a number, got " + type(val).__name__
                )
            return -val
        elif node.operator == '!':
            return not is_truthy(val)

RESULT
------------------------------
    -"hello";
    ->  WispRuntimeError: operand of unary '-' must be a number, got str

WHY THIS WORKS AS AN ANSWER
------------------------------
It's caught cleanly -- and specifically because of the
"if not isinstance(val, float)" check on the line immediately before
the actual negation. Unlike visit_binary's arithmetic and comparison
cases (which needed this exercise's own Exercise 1 to add the check
for a NEW operator), unary minus already had its type check written
in the chapter itself, for the same reason division and multiplication
did: `-val` on a Python string would raise
`TypeError: bad operand type for unary -: 'str'`, a raw Python message
about Python's own unary minus, not about Wisp's.

The one operator in visit_unary that genuinely needs NO type check is
'!' -- is_truthy() is defined to accept literally any Wisp value
(None, bool, float, str) and always return a bool, by design, so there
is no invalid input for it to guard against. That asymmetry is worth
noticing: '-' is a numeric operator restricted to one type, while '!'
is a boolean operator defined over every type Wisp has -- the type
check belongs on the operator that's actually restricted, not
reflexively on every unary operator.