1
1
mirror of https://github.com/sdiehl/wiwinwlh.git synced 2024-09-11 12:05:25 +03:00

Write more

This commit is contained in:
sdiehl 2020-02-13 16:33:07 +00:00
parent 3cdeaba85d
commit 06fd31632d
2 changed files with 17 additions and 14 deletions

View File

@ -32,6 +32,8 @@ This text is authored by Stephen Diehl.
\item Github: https://github.com/sdiehl \item Github: https://github.com/sdiehl
\end{enumerate} \end{enumerate}
Special thanks for Erik Aker for copyediting assitance.
Copyright \textcopyright \ 2009-2020 Stephen Diehl Copyright \textcopyright \ 2009-2020 Stephen Diehl
This code included in the text is dedicated to the public domain. You can copy, This code included in the text is dedicated to the public domain. You can copy,

View File

@ -186,7 +186,7 @@ To modify your shell to include ghc and cabal.
$ source ~/.ghcup/env $ source ~/.ghcup/env
``` ```
Or permanently add the following to your `.bashrc` or `.zshrc` file: Or you can permanently add the following to your `.bashrc` or `.zshrc` file:
```bash ```bash
export PATH="~/.ghcup/bin:$PATH" export PATH="~/.ghcup/bin:$PATH"
@ -201,12 +201,13 @@ package level. So, why are there two different package managers?
The simplest explanation is that Haskell is an organic ecosystem with no central The simplest explanation is that Haskell is an organic ecosystem with no central
authority, and as such different groups of people with different ideas and authority, and as such different groups of people with different ideas and
different economic interests about optimal packaging built around two different different economic interests about optimal packaging built their own solutions
models. The interests of an organic community don't always result in open source around two different models. The interests of an organic community don't always
convergence, however the ecosystem has seen both package managers reach much result in open source convergence; however, the ecosystem has seen both package
greater levels of stability as a result of collaboration. In this article I managers reach much greater levels of stability as a result of collaboration. In
won't make a preference which system to use, this is best left up to the reader this article, I won't offer a preference for which system to use: it is left up
to experiment and use the system which best your or your company's needs. to the reader to experiment and use the system which best suits your or your
company's needs.
Project Structure Project Structure
----------------- -----------------
@ -233,9 +234,9 @@ file structure:
└── .ghci # ghci configuration └── .ghci # ghci configuration
``` ```
More complex projects consisting of multiple components will have use a multiple More complex projects consisting of multiple components will include multiple
projects like above, but nested in subfolders with a `cabal.project` or project directories like that above, but these will be nested in subfolders with
`stack.yaml` in the root of the repository. a `cabal.project` or `stack.yaml` in the root of the repository.
```bash ```bash
. .
@ -246,8 +247,8 @@ projects like above, but nested in subfolders with a `cabal.project` or
└── cabal.project # cabal project configuration └── cabal.project # cabal project configuration
``` ```
An example Cabal project `cabal.project1` for the above multi-component library An example Cabal project file, named `cabal.project1` above, this
repository would look like: multi-component library repository would include these lines.
```yaml ```yaml
packages: ./lib-one packages: ./lib-one
@ -255,8 +256,8 @@ packages: ./lib-one
./lib-three ./lib-three
``` ```
While an example Stack project `stack.yaml` for the above multi-component library By contract, an example Stack project `stack.yaml` for the above multi-component
repository would be: library repository would be:
```yaml ```yaml
resolver: lts-14.20 resolver: lts-14.20