Challenge 2: Concatenating Three Difference Lists — Possible Solution
====================================================================

dl_demo.pl:

dl_concat(A-B, B-C, A-C).

Query:

    ?- L1 = [a, b | H1], DL1 = L1-H1,
       L2 = [c, d | H2], DL2 = L2-H2,
       L3 = [e, f | H3], DL3 = L3-H3,
       dl_concat(DL1, DL2, Mid-H2),
       dl_concat(Mid-H2, DL3, Combined-H3),
       H3 = [].
    Combined = [a, b, c, d, e, f].

-- Why does this stay O(1) per concatenation regardless of list length? --
--
-- Each dl_concat/3 call is still just ONE unification -- the first
-- pair's hole variable gets unified with the second pair's own list
-- term. The first call (DL1, DL2) splices L2 into H1, exactly as in
-- Challenge 1, giving an open list ending in H2. The second call
-- (that result, DL3) splices L3 into H2 the exact same way -- one
-- more unification, completely independent of how long L1, L2, or
-- L3 individually are. Neither call ever walks any list's actual
-- elements to perform the splice -- Prolog's unification directly
-- attaches one term to another via the shared hole variable. Three
-- lists combined this way cost exactly two O(1) unifications total,
-- not two O(length) append/3-style walks -- the cost genuinely
-- doesn't grow with how many elements are inside any of the lists
-- being joined, only with how many separate concatenations are
-- performed.

WHY THIS WORKS AS AN ANSWER
------------------------------
This chains two dl_concat/3 calls to combine three difference lists
into one, then explicitly ties the O(1)-per-call claim back to the
mechanism (a single hole-to-list unification, not an element-by-element
walk), showing why the technique's cost scales with the number of
concatenations rather than the length of any individual list.