         def blank?(data)
       end
 
-  Which can now be implemented as:
+  The `Blank` protocol can now be implemented for `Any`:
 
       defimpl Blank, for: Any do
         def blank?(_), do: true
       end
 
-  One may wonder why such fallback is not true by default.
+  One may wonder why such behaviour (fallback to any) is not the default one.
 
   It is two-fold: first, the majority of protocols cannot
-  implement an action in a generic way for all types. In fact,
+  implement an action in a generic way for all types; in fact,
   providing a default implementation may be harmful, because users
   may rely on the default implementation instead of providing a
   specialized one.
 
   Second, falling back to `Any` adds an extra lookup to all types,
-  which is unnecessary overhead unless an implementation for Any is
+  which is unnecessary overhead unless an implementation for `Any` is
   required.
 
   ## Types
 
   Defining a protocol automatically defines a type named `t`, which
-  can be used as:
+  can be used as follows:
 
       @spec present?(Blank.t) :: boolean
       def present?(blank) do


  ## Nesting

  Nesting a module inside another module affects its name:

      defmodule Foo do
        defmodule Bar do
        end
      end

  In the example above, two modules `Foo` and `Foo.Bar` are created.
  When nesting, Elixir automatically creates an alias, allowing the
  second module `Foo.Bar` to be accessed as `Bar` in the same lexical
  scope.

  This means that, if the module `Bar` is moved to another file,
  the references to `Bar` needs to be updated or an alias needs to
  be explicitly set with the help of `Kernel.SpecialForms.alias/2`.

  ## Dynamic names

  Elixir module names can be dynamically generated. This is very
  useful for macros. For instance, one could write:

      defmodule String.to_atom("Foo#{1}") do
        # contents ...
      end

  Elixir will accept any module name as long as the expression
  returns an atom. Note that, when a dynamic name is used, Elixir
  won't nest the name under the current module nor automatically
  set up an alias.
  """
  defmacro defmodule(alias, do: block) do
    env   = __CALLER__

  Defines an exception.

  Exceptions are structs backed by a module that implements
  the `Exception` behaviour. The `Exception` behaviour requires
  two functions to be implemented:

    * `exception/1` - receives the arguments given to `raise/2`
       and returns the exception struct. The default implementation
       accepts a set of keyword arguments that is merged into the
       struct.

    * `message/1` - receives the exception struct and must return its
      message. Most commonly exceptions have a message field which
      by default is accessed by this function. However, if an exception
      does not have a message field, this function must be explicitly
      implemented.

  Since exceptions are structs, the API supported by `defstruct/1`
  is also available in `defexception/1`.

  ## Raising exceptions

  The most common way to raise an exception is via `raise/2`:

      defmodule MyAppError do
        defexception [:message]
