haskell/cabal-lib: Edits

2 files changed, 12 insertions, 12 deletions

diff --git a/haskell/cabal-lib.html b/haskell/cabal-lib.html
index 9f93c19..80be102 100644
--- a/haskell/cabal-lib.html
+++ b/haskell/cabal-lib.html
@@ -89,11 +89,11 @@ active package flags:
   -package-id brick-1.10-1f76dfaf75736c0f6e2a4a2cf992bb12da05f6bbc7985f9787547739947e4696
 </code></pre>
 <p>and you can even make that change permanent with <code>cabal install --lib base</code>, which adds (in my case) a line <code>package-id base-4.17.2.0</code> to the aforementioned <code>default</code> file.</p>
-<p>In short, a <em>GHC environment file</em> was created by <code>cabal</code> that contains a list of packages in scope for <code>ghc</code> when you're accessing <code>GHC</code> through <code>cabal</code> in the context of a project.
+<p>In short, a <em>GHC environment file</em> was created by <code>cabal</code> that contains a list of packages in scope for <code>ghc</code> when you're not using <code>cabal</code>, or outside the context of a project.
 You need to either manage this file manually or through some <a href="https://github.com/phadej/cabal-extras">helper tool</a>, and you will need to, because <code>cabal</code> won't resolve conflicts for you.
 You're back to manual, imperative management of dependencies.</p>
-<p>Furthermore, this way of installing dependencies is fundamentally separate from the code that <em>uses</em> those dependencies, and is just one such list.
-So if you have multiple scripts that you'd like to work globally, outside of a project, their dependency sets had better be compatible.</p>
+<p>Furthermore, this way of installing dependencies is fundamentally separate from the code that <em>uses</em> those dependencies, and there is just <em>one</em> such global list.
+So if you have multiple Haskell programs that you'd like to work globally, outside of a project, their dependency sets had better be compatible, or things will break.</p>
 <h2>How to fix the situation</h2>
 <p>If you got yourself in a pickle due to an unintended use of <code>cabal install --lib</code>, you can undo its effects (apart from having used some disk space in compiling the packages in question) by removing the <code>default</code> file mentioned above.
 This is in <code>~/.ghc/<em>architecture</em>-<em>OS</em>-<em>ghcversion</em>/environments/default</code>.</p>
@@ -101,7 +101,7 @@ This is in <code>~/.ghc/<em>architecture</em>-<em>OS</em>-<em>ghcversion</em>/en
 Removing the entire store folder for a particular GHC version is safe, however -- even though this does of course mean that you may need to recompile a lot of things later. :)</p>
 <h2>What to do instead</h2>
 <p>Create a project!
-The intended mode of operation of the modern Haskell tooling, that is <code>cabal</code> and <code>stack</code>, is to always work inside of a <em>project</em>.
+The intended mode of operation of the modern Haskell tooling, that is <code>cabal</code> or <code>stack</code>, is to always work inside of a <em>project</em>.
 Often, &quot;project&quot; basically means &quot;package&quot;, but you can have projects with multiple packages in them (using a <code>cabal.project</code> file, see <a href="https://cabal.readthedocs.io/en/3.10/cabal-project.html">the docs</a>).</p>
 <p>Creating a package is easily done using <code>cabal init --simple</code> inside a fresh directory.
 If you like to be asked more questions, you can also opt for <code>cabal init</code> instead.
@@ -111,8 +111,8 @@ Put a comma (<code>,</code>) between the package names in the <code>build-depend
 A package (a single thing in the package repository, should you decide to upload it to Hackage at some point) can contain multiple components: possibly one public library, as well as zero or more executables, test suites, or benchmarks.
 (There is also the concept of an &quot;internal library&quot;, for which see <a href="https://cabal.readthedocs.io/en/3.10/cabal-package.html#sublibs">the documentation</a>, but don't worry about that.)</p>
 <p>You can start writing code in the <code>app/Main.hs</code> file (or <code>src/MyLib.hs</code> file if you selected Library) and run using <code>cabal run</code> (or build using <code>cabal build</code> in the case of a library).
-<code>cabal</code> will automatically ensure that a consistent set of versions is compiled and made available, if at all possible.
-You can add <a href="https://cabal.readthedocs.io/en/3.10/cabal-package.html#pkg-field-build-depends">version bounds</a> to your dependencies if you want to apply some proper software engineering principles.</p>
+<strong><code>cabal</code> will automatically ensure that a consistent set of versions is compiled and made available, if at all possible.</strong>
+You can also add <a href="https://cabal.readthedocs.io/en/3.10/cabal-package.html#pkg-field-build-depends">version bounds</a> to your dependencies if you want to apply some proper software engineering principles.</p>
 <p>(If you want to use <code>stack</code> instead of <code>cabal</code>, try <a href="https://docs.haskellstack.org/en/stable/GUIDE/">their getting started guide</a>.)</p>
 <h3>An even lighter-weight alternative</h3>
 <p>An alternative to creating a project is to make a <em>cabal script</em>: this allows you to effectively make a self-contained project inside a single Haskell file.
diff --git a/haskell/cabal-lib.md b/haskell/cabal-lib.md
index 2504fc8..3688d05 100644
--- a/haskell/cabal-lib.md
+++ b/haskell/cabal-lib.md
@@ -131,12 +131,12 @@ active package flags:
 
 and you can even make that change permanent with `cabal install --lib base`, which adds (in my case) a line `package-id base-4.17.2.0` to the aforementioned `default` file.
 
-In short, a _GHC environment file_ was created by `cabal` that contains a list of packages in scope for `ghc` when you're accessing `GHC` through `cabal` in the context of a project.
+In short, a _GHC environment file_ was created by `cabal` that contains a list of packages in scope for `ghc` when you're not using `cabal`, or outside the context of a project.
 You need to either manage this file manually or through some [helper tool](https://github.com/phadej/cabal-extras), and you will need to, because `cabal` won't resolve conflicts for you.
 You're back to manual, imperative management of dependencies.
 
-Furthermore, this way of installing dependencies is fundamentally separate from the code that _uses_ those dependencies, and is just one such list.
-So if you have multiple scripts that you'd like to work globally, outside of a project, their dependency sets had better be compatible.
+Furthermore, this way of installing dependencies is fundamentally separate from the code that _uses_ those dependencies, and there is just _one_ such global list.
+So if you have multiple Haskell programs that you'd like to work globally, outside of a project, their dependency sets had better be compatible, or things will break.
 
 
 ## How to fix the situation
@@ -151,7 +151,7 @@ Removing the entire store folder for a particular GHC version is safe, however -
 ## What to do instead
 
 Create a project!
-The intended mode of operation of the modern Haskell tooling, that is `cabal` and `stack`, is to always work inside of a _project_.
+The intended mode of operation of the modern Haskell tooling, that is `cabal` or `stack`, is to always work inside of a _project_.
 Often, "project" basically means "package", but you can have projects with multiple packages in them (using a `cabal.project` file, see [the docs](https://cabal.readthedocs.io/en/3.10/cabal-project.html)).
 
 Creating a package is easily done using `cabal init --simple` inside a fresh directory.
@@ -164,8 +164,8 @@ A package (a single thing in the package repository, should you decide to upload
 (There is also the concept of an "internal library", for which see [the documentation](https://cabal.readthedocs.io/en/3.10/cabal-package.html#sublibs), but don't worry about that.)
 
 You can start writing code in the `app/Main.hs` file (or `src/MyLib.hs` file if you selected Library) and run using `cabal run` (or build using `cabal build` in the case of a library).
-`cabal` will automatically ensure that a consistent set of versions is compiled and made available, if at all possible.
-You can add [version bounds](https://cabal.readthedocs.io/en/3.10/cabal-package.html#pkg-field-build-depends) to your dependencies if you want to apply some proper software engineering principles.
+**`cabal` will automatically ensure that a consistent set of versions is compiled and made available, if at all possible.**
+You can also add [version bounds](https://cabal.readthedocs.io/en/3.10/cabal-package.html#pkg-field-build-depends) to your dependencies if you want to apply some proper software engineering principles.
 
 (If you want to use `stack` instead of `cabal`, try [their getting started guide](https://docs.haskellstack.org/en/stable/GUIDE/).)