Cleanup docs

README.md

@@ -1,18 +1,18 @@
 # ghc-specter
-Inspecting tool for the GHC pipeline through GHC plugin
+Inspecting tool for the [GHC](https://github.com/ghc/ghc) pipeline through GHC plugin
 
-ghc-specter is an inspecting tool and visualizer of internal states of
+`ghc-specter` is an inspecting tool and visualizer of internal states of
 the GHC compilation pipeline via GHC plugins and hooks. Haskell developers
 often need investigation in the middle of the compilation, for example,
 to identify blocking compilation steps dominating the build time or to
-investigate a problematic Template Haskell code, but have to rely only on
-built-in GHC logging or resort to a custom modification of the GHC source
-code. As a GHC driver plugin, invoked by simple command-line flags,
-ghc-specter collects the relevant information directly inside from the GHC
-compilation and send to a visualizer daemon on live. The user can also pause
-and intervene the GHC process in the middle of compilation to inspect the
-GHC internal state and inspect the the compilation process in an interactive
-session.
+investigate a problematic [Template Haskell](https://wiki.haskell.org/Template_Haskell) 
+code, but have to rely only on built-in GHC logging or resort to a custom 
+modification of the GHC source code. As a GHC driver plugin, invoked by simple 
+command-line flags, `ghc-specter` collects the relevant information directly 
+inside from the GHC compilation and sends this to a live visualizer daemon.
+The user can also pause and intervene the GHC process in the middle of 
+compilation to inspect the GHC internal state and inspect the compilation 
+process in an interactive session.
 
 ## How to use
 

docs/how-it-works.rst

@@ -38,37 +38,38 @@ GHC Mode
 When invoked from the Command-Line-Interface (CLI), GHC is run in a certain mode.
 As we all are familiar, GHC can be used as both compiler and interpreter.
 In fact, this is one of the special luxurious features of GHC that we Haskell
-developers all enjoy. GHC compiler seamlessly integrates the interpreter
+developers all enjoy. The GHC compiler seamlessly integrates the interpreter
 read-eval-print-loop (REPL) session. GHC interpreter and the Run-Time-System (RTS)
 allows one to mix interpreted codes with other precompiled native binary
 bytecode.
 
 The compiler mode (or batch mode) can be run (i) in compilation manager mode
-(``--make``) in which a single GHC session will make a build plan (by topolically
+(``--make``) in which a single GHC session will make a build plan (by topologically
 ordering module graph) and compile a group of modules associated with their source
 codes, or (ii) in oneshot mode (``-c``) in which only a single module is built for
 that GHC process. As the compilation starts, per module, a single GHC pipeline
 is carried out in a sequence of phases as explained in the next subsection.
 
-The interpreter mode compiles source codes or load precompiled modules dynamically
-from the user demand in a REPL session. Therefore, the interpreter mode is a
+The interpreter mode compiles source codes or loads precompiled modules dynamically
+from the user in a REPL session. Therefore, the interpreter mode is a
 trampoline process between a REPL session and compilation pipeline. When compiling
 a source file as demanded, the same GHC pipeline is invoked, so the plugins
 associated to each phase will be invoked as the compiler mode. But the backend
-phases for generating Cmm and assembly codes and linking is not performed since
-it is unnecessary.
+phases for generating `Cmm <https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/rts/cmm>`
+and assembly codes and linking is not performed since it is unnecessary.
 
 Phases and internal representation
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 A single module is being compiled in a single pipeline thread. In large chunks,
 the pipeline consists of the frontend phases, the backend phases and the external
 assembler/linker phases. The frontend phases starts with source codes, and
-parsing, typechecking, desugaring, and results in GHC Core. The GHC Core is
-optimized in a few Core-to-Core passes. Then, the backend phases generate
-the STG and Cmm representation, and finally generates assembly codes or LLVM IR
-depending on the configuration. Afterwards, the external assembler and linker
-(such as gcc or clang toolchain) will create a linkable binary.
+parsing, typechecking, `desugaring <https://serokell.io/blog/haskell-to-core>`,
+and results in GHC Core. The GHC Core is optimized in a few Core-to-Core passes.
+Then, the backend phases generate the STG and Cmm representation, and finally
+generates assembly codes or LLVM IR depending on the configuration.
+Afterwards, the external assembler and linker (such as gcc or clang toolchain)
+will create a linkable binary.
 
 The frontend phase may start with a preprocessor (such as ``hsc2hs``). The
 compilation may end before the external linking process. For example, for the
@@ -124,8 +125,8 @@ sorted. Then, each module compilation is swept over the ordered list with the gl
 Right after parsing the source code, the names in the parsed module are extracted but not yet bound to known
 imported/declared names, and conflicting names are not resolved with unique IDs. Therefore, the compiler
 does the ``Renamed`` pass. The information extracted and resolved should be accumulated into a global map,
-``GlobalRdrEnv``. After the name resolution and issuing unique IDs, typechecker pass will follow and develop
-another global map as a part of compilation state, collecting typechecking evidences.
+``GlobalRdrEnv``. After the name resolution and issuing unique IDs, the typechecker pass will follow and develop
+another global map as a part of the compilation state, collecting typechecking evidence.
 Combining such maps with the fully resolved Haskell AST, the accumulated ``TcGblEnv`` is produced as the
 result of the frontend typechecker and passed to the ``HscPostTc`` phase.