         @impl true
         def init(_init_arg) do
           children = [
-            {Stack, [:hello]}
+            {Counter, 0}
           ]
 
           Supervisor.init(children, strategy: :one_for_one)

      #=> %{active: 1, specs: 1, supervisors: 0, workers: 1}

  Note that when starting the GenServer, we are registering it
  with name `Stack`, which allows us to call it directly and get
  what is on the stack:

      GenServer.call(Stack, :pop)
      #=> :hello

      GenServer.cast(Stack, {:push, :world})
      #=> :ok

      GenServer.call(Stack, :pop)
      #=> :world

  However, there is a bug in our stack server. If we call `:pop` and
  the stack is empty, it is going to crash because no clause matches:

      GenServer.call(Stack, :pop)
      ** (exit) exited in: GenServer.call(Stack, :pop, 5000)

  Luckily, since the server is being supervised by a supervisor, the
  supervisor will automatically start a new one, with the initial stack
  of `[:hello]`:

      GenServer.call(Stack, :pop)
      #=> :hello

  Supervisors support different strategies; in the example above, we
  have chosen `:one_for_one`. Furthermore, each supervisor can have many

  restart each of its children:

      %{
        id: Counter,
        start: {Counter, :start_link, [0]}
      }

  The map above defines a child with `:id` of `Counter` that is started
  by calling `Counter.start_link(0)`.

  However, specifying the child specification for each child as a map can be
  quite error prone, as we may change the `Counter` implementation and forget
  to update its specification. That's why Elixir allows you to pass a tuple with
  the module name and the `start_link` argument instead of the specification:

      children = [
        {Counter, 0}
      ]

  The supervisor will then invoke `Counter.child_spec([:hello])` to retrieve a
  child specification. Now the `Counter` module is responsible for building its
  own specification, for example, we could write:

      def child_spec(arg) do
        %{
          id: Counter,
          start: {Counter, :start_link, [arg]}
        }
      end

  Luckily for us, `use GenServer` already defines a `Counter.child_spec/1`
  exactly like above, so you don't need to write the definition above yourself.
  If you want to customize the automatically generated `child_spec/1` function,
  you can pass the options directly to `use GenServer`:

      use GenServer, restart: :transient

  Finally, note it is also possible to simply pass the `Counter` module as
  a child:

      children = [
        Counter
      ]

  When only the module name is given, it is equivalent to `{Counter, []}`,
  which in our case would be invalid, which is why we always pass the initial
  counter explicitly.

  By replacing the map specification by `{Counter, 0}`, we keep the child
  specification encapsulated in the `Counter` module. We could now share our
  `Counter` implementation with other developers and they can add it directly
  to their supervision tree without worrying about the low-level details of
  the counter.

  Overall, the child specification can be one of the following:

    * 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 `{Counter, 0}`. In this case, `Counter.child_spec(0)` is called
      to retrieve the child specification

    * a module - such as `Counter`. In this case, `Counter.child_spec([])`
      would be called, which is invalid for the counter, but it is useful in
      many other cases, especially when you want to pass a list of options
      to the child process

  If you need to convert a tuple or a module child specification to a map or
  modify a child specification, you can use the `Supervisor.child_spec/2` function.
  For example, to run the counter with a different `:id` and a `:shutdown` value of
  10 seconds (10_000 milliseconds):

      children = [
        Supervisor.child_spec({Counter, 0}, id: MyCounter, shutdown: 10_000)
      ]

  ## Supervisor strategies and options

  So far we have started the supervisor passing a single child as a tuple
  as well as a strategy called `:one_for_one`:

      children = [
        {Counter, 0}
      ]

      Supervisor.start_link(children, strategy: :one_for_one)

  The first argument given to `start_link/2` is a list of child
  specifications as defined in the "child_spec/1" section above.

  The second argument is a keyword list of options:

    * `:strategy` - the supervision strategy option. It can be either
      `:one_for_one`, `:rest_for_one` or `:one_for_all`. Required.
      See the "Strategies" section.

    * `:max_restarts` - the maximum number of restarts allowed in
      a time frame. Defaults to `3`.

    * `:max_seconds` - the time frame in which `:max_restarts` applies.
      Defaults to `5`.

    * `:name` - a name to register the supervisor process. Supported values are
      explained in the "Name registration" section in the documentation for
      `GenServer`. Optional.

  ### Strategies

  Supervisors support different supervision strategies (through the
  `:strategy` option, as seen above):

    * `:one_for_one` - if a child process terminates, only that
      process is restarted.

    * `:one_for_all` - if a child process terminates, all other child
      processes are terminated and then all child processes (including
      the terminated one) are restarted.

    * `:rest_for_one` - if a child process terminates, the terminated child
      process and the rest of the children started after it, are terminated and
      restarted.

  In the above, process termination refers to unsuccessful termination, which
  is determined by the `:restart` option.

  To dynamically supervise children, see `DynamicSupervisor`.

  ### Name registration

  A supervisor is bound to the same name registration rules as a `GenServer`.
  Read more about these rules in the documentation for `GenServer`.

  ## Module-based supervisors

  In the example so far, the supervisor was started by passing the supervision
  structure to `start_link/2`. However, supervisors can also be created by
  explicitly defining a supervision module:

