Challenge 1: Extending can_fly/1 With flightless/1 — Possible Solution
====================================================================

birds.pl:

bird(tweety).
bird(polly).
bird(pingu).
bird(ostrich).

penguin(pingu).
flightless(ostrich).

can_fly(X) :- bird(X), \+ penguin(X), \+ flightless(X).

Queries:

    ?- can_fly(tweety).
    true.

    ?- can_fly(pingu).
    false.

    ?- can_fly(ostrich).
    false.

Explanation:
can_fly/1 now chains two separate negation-as-failure checks with an
ordinary conjunction: bird(X) confirms X is a bird at all, then
\+ penguin(X) and \+ flightless(X) each have to succeed (meaning
neither penguin(X) nor flightless(X) can be proven) for the whole
rule to succeed. can_fly(ostrich) fails specifically because
flightless(ostrich) is a fact in the database, making \+
flightless(ostrich) fail -- exactly the same mechanism that already
made can_fly(pingu) fail via penguin(pingu), just triggered by a
different exception fact. Both checks can independently disqualify a
bird from flying, and either one being provable is enough to make
can_fly fail.

WHY THIS WORKS AS AN ANSWER
------------------------------
This extends the chapter's own can_fly/1 pattern with a second,
independent negated condition rather than just repeating the
original penguin example, and confirms ostrich is correctly excluded
via the newly added flightless/1 check, without disturbing the
existing penguin-based exclusion.