/**
Wrapping up Prolog:
  Why?  Why is some prolog-programming included in this course?
  As an example of "experience with declarative programming" sure,
  but that begs the question: why does this course feel that
  such exposure is worthwhile -- what're you going to get out of it?

  Non-answer: You may use prolog in the future.  (You won't.)
  Half-answer 1: the feature of matching(destructuring&naming) inputs
    is very cool, and has been added to many modern languages
    (python has v.limited pattern matching (just destructuring) for variable-assignment; 
     Rust and Java allow pattern-matching w/ destructuring structs/records;
     and racket has a full-fledged `match`).
    All true, but that's not enough to spend 1.5w on (other) prolog.
  Half-answer 2: experience with a truly/obviously declarative language.
    Yeah, that's part of it.
  Full-answer: It changes your entire perspective on what an interface-spec
    can be!  [And the interface/implementation separation is fundamental to our field.]
    Seeing that the interface(purpose) of, say, 'sort' can be described SO WELL
    THAT IT CAN BE RUNNABLE CODE (albeit inefficient, since implementation is ignored),
    helps shape how you'll write interface documentation / specs in the future:
    write the spec precisely, while omitting all implementation details.
    E.g. post-conditions can be expressed as actual code:
           `(sort nums <=)` gives a [rslt] such that:
           (apply <= [rslt]) is true,  and for all t in nums, (member t [rslt]).  (*)


   (*) Really I need to say `permutation` rather than just `member, for all t`,
       since duplicates need to be spec'd.
**/