         {Stack, [:hello]}
       ], strategy: :one_for_one)
 
-  However, children can be specified in three different formats and
-  supervisors support different options. Let's formally define those.
+  Although we have mentioned that the supervisor automatically expands
+  `{Stack, [:hello]}` to a child specification by calling
+  `Stack.child_spec([:hello])`, we haven't formally defined all of the
+  arguments accepted by `start_link/2` and `init/2`. Let's rectify that
+  now.
 
   The first argument given to `start_link/2` is a list of children which may
   be either:
 
-    * a module - such as `Stack`. In this case, it is equivalent to passing
-      `{Stack, []}` (which means `Stack.child_spec/1` is invoked with an empty
-      keywords list)
+    * a map representing the child specification itself - as outlined in the
+      "Child specification" section
     * a tuple with a module as first element and the start argument as second -
-      such as `{Stack, [:hello]}`. When such format is used, the supervisor
-      will retrieve the child specification from the given module.
-    * a map representing the child specification itself - such as the child
-      specification map outlined in the previous section.
+      such as `{Stack, [:hello]}`. In this case, `Stack.child_spec([:hello])`
+      is called to retrieve the child specification
+    * a module - such as `Stack`. In this case, `Stack.child_spec([])`
+      is called to retrieve the child specification
 
   The second argument is a keyword list of options:
 

  and to get the top of the stack by pattern matching.

  We can now start a supervisor that will start and supervise our
  stack process as follows:

      # Start the supervisor with the stack as a single child.
      #
      # The first element of the tuple is the module containing
      # the child implementation, the second is the argument
      # given to start_link, in this case a stack with `:hello`.
      {:ok, pid} = Supervisor.start_link([
        {Stack, [:hello]}
      ], strategy: :one_for_one)

      # After started, we can query the supervisor for information
      Supervisor.count_children(pid)

  The rest of this document will cover how child processes are started,
  how they can be specified, different supervision strategies and more.

  ## child_spec/1

  When starting a supervisor, we pass a list of child specifications.
  Those specifications are maps that tell how the supervisor should
  start, stop and restart each of its children:

      %{
        id: Stack,
        start: {Stack, :start_link, [[:hello]]}
      }

  The map above defines a supervisor with `:id` of `Stack` that is started
  by calling `Stack.start_link([:hello])`. There are other options we can
  set in the specification and we will explore those in the next sections.

  For now, however, we want to clarify that specifying the child specification
  for each child as a map is repetitive and error prone. That's why Elixir
  allows you to simply pass the module name or a tuple with the module name
  and the `start_link` argument instead of the child specification:

      children = [
        {Stack, [:hello]}
      ]

  In this case, the supervisor will invoke `Stack.child_spec([:hello])` which
  then returns the child specification. It is also possible to simply pass the
  `Stack` module as a child:

      children = [
        Stack # equivalent to {Stack, []}
      ]

  The advantage of this approach is that you can now share your `Stack` service
  with other developers and they can add it directly to their supervision tree
  without worrying about the low-level details of the service.

  In case you need to access or modify how a service runs, you can use the
  `child_spec/2` function defined in this module. To run the stack with a different
  `:id`:

      children = [
        Supervisor.child_spec({Stack, [:hello]}, id: MyStack)
      ]

  We can see the child specification the call above returns:

      Supervisor.child_spec({Stack, [:hello]}, id: MyStack)
      #=> %{id: MyStack, start: {Stack, :start_link, [[:hello]]}}

  The `child_spec/1` function was automatically defined in our `Stack` module
  by `use GenServer`. You can also configure the GenServer to use a different
  `:id` or to use a `:shutdown` value of 10 seconds (10_000 milliseconds) when
  the `Stack` is defined:

      use GenServer, id: MyStack
      use GenServer, shutdown: 10_000

  Let's learn more about how supervisors start and shutdown.

  ## Start and shutdown

  When the supervisor starts, it traverses all children and retrieves
  each child specification. It is at this moment `{Stack, [:hello]}`
  becomes a child specification by calling `Stack.child_spec([:hello])`.

  Then the supervisor starts each child in the order they are defined.
  This is done by calling the function defined under the `:start` key
  in the child specification and typically defaults to `start_link/1`.

  The `start_link/1` (or a custom) is then called for each child process.
  The `start_link/1` function must return `{:ok, pid}` where `pid` is the
  process identifier of a new process that is linked to the supervisor.
  The child process usually starts its work by executing the `init/1`
  callback. Generally speaking, the `init` callback is where we initialize
  and configure the child process.

  The shutdown process happens in reverse order.

  When a supervisor shuts down, it terminates all children in the opposite
  order they are listed. The termination happens by sending a shutdown exit
  signal, via `Process.exit(child_pid, :shutdown)`, to the child process and
  then awaiting for a time interval for the child process to terminate. This
  interval defaults to 5000 milliseconds. If the child process does not
  terminate in this interval, the supervisor abruptly terminates the child
  with reason `:brutal_kill`. The shutdown time can be configured in the
  child specification which is fully detailed in the next section.

  If the child process is not trapping exits, it will shutdown immediately
  when it receives the first exit signal. If the child process is trapping
