sdiehl/wiwinwlh
1
1
Fork 0
mirror of https://github.com/sdiehl/wiwinwlh.git synced 2024-08-16 23:40:41 +03:00
Code Issues Projects Releases Wiki Activity

Write more

Browse Source
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
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
resources/copyright.tex
View File

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

29
tutorial.md
View File

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