GitLab

Problem: we can use the existing tutorial to make a static website
for Indigo using mkdocs.
This needs changed in the documentation's content, namely:
- we would like to statically include part of the example modules
- there needs to be an index/home page
- the appendices should be moved to be "reference" pages
- the explanations should not be flat, but include note blocks, etc.
- references to local files need to be removed, as they don't work

Solution: Make a buildable website with:
- configuration for mkdocs and its extension
- CSS for customized styling
- a python-markdown extension for example source code inclusion

Problem: A website for Indigo needs to be built from its current
tutorial, however the tree structure is not ideal, in particular:
- markdown files for the chapters are organized alonside the source
  code for the examples
- the example modules are tied to the documentation structure
These constitute a problem because we want the documentation's file
tree structure to be independent from the examples and vice-versa.

Solution: move the markdown files in a flat new directory and move
the example modules in a topic-based tree structure.

Problem: Currently `contractCallingUnsafe` uses `EpName` for its
argument which possesses a problem for a beginners to properly use.

Solution: Define `buildEpName` and `unsafeBuildEpName` functions and
update the tutorial.

Problem: some operators in Indigo are named in an odd way (usually with
a `.`) to avoid conflicts with Haskell operators, additionally many of
them operating on structures have been added organically and do not
follow any convention, being confusing.
Moreover, many of them do not have a prefix counterpart, which may be
useful to have available.

Solution: rename operators, replacing the ones from Prelude in case of
name clashing and based on a convention in case of structure-based.
Addionally, add all necessary prefix counterpart using the names of
Michelson instructions where one exists.

Problem: We are using `base-noprelude` dependency which is not a
standard package. We can use `base` instead and just hide its
`Prelude` module using `mixins` feature of Cabal. The advantage is
that we will have less dependencies.

Solution: Remove `base-noprelude`, use `base` with mixin `hiding
Prelude` instead.

Problem: `whileLeft` has not been
ported to Indigo from Lorentz yet.

Solution: Add `whileLeft` to Indigo.

Problem: `ifCons` has not been
ported to Indigo from Lorentz yet.

Solution: Add `ifCons` to Indigo and add `withSIS2`
which is used to implement `ifCons`.

to Indigo

Problem: `left`, `right`, `ifLeft`, `ifRight`, `whenLeft`, `whenRight`
have not been ported to Indigo from Lorentz yet.

Solution: Add `left`, `right`, `ifLeft`, `ifRight`, `whenLeft`, `whenRight`
to Indigo.

Problem: `ifNone` has not been
ported to Indigo from Lorentz yet.

Solution: Add `ifNone` to Indigo.

Problem: We have decided that using `OverloadedLists` extension in
indigo is not a good idea because it leads to many breakages and
needed workarounds to make them work as expected. So we've decided
to close this issue and with this commit we remove all of its
appearances.

Solution: Remove a TODO from the second appendix of indigo tutorial.

Problem: currently the address of any originated contract is calculated,
essentially, as a hash of its JSON-encoded code and initial storage.
This means that multiple originations of the same contract lead to the
identical addresses, contrary to what reference Tezos does.

Solution: include a global operation counter and in-operation
origination nonce to the calculation of the addresses. Match Tezos's
encoding of addresses more closely, namely dervive addresses from any
global operation that led to origination, not the immediate
OriginationOperation.

Problem:  We have `nonZero` in Lorentz that returns Nothing if the
value is `0`, and `Just` the value otherwise.
There is however no equivalent to it in Indigo.

Solution: Add `nonZero` expression equivalent to its Lorentz homonym

Problem: Indigo code often contains the `$` Haskell operator,
however since the language is meant to be used by people not
familiar with Haskell it would be great to not make it a necessity.

Solution: Reduce usage of `$` in 2 places:

1. right before `do` is used for a block code
- Solved by using `BlockArguments`

2. right after `new`
- Solved by treating `new$` as one keyword

Problem: There is a TODO comment related to `xor` issue that is not removed.

Solution: Remove the TODO comment.

Problem: Indigo has a `concat` expression to concat 2 values and
`concat'` to concatenate a list of values. We want to keep `concat`
since it has an equivalent to Michelson's `CONCAT`. However,
`concat'` can be confusing, it is better to rename this.

Solution: Rename `concat'` to `concatAll`

Problem: Current `stack ghci indigo` causes ambiguous error
`Ambiguous occurrence ‘>>=’ `. A workaround is to load the file
directly `stack ghci code/indigo/src/Indigo.hs`, but that is not ideal.

Solution: By using stack target syntax, we can add an executable
component inside indigo, and only load that executable via `stack
ghci :indigo-repl`.

Problem: `construct`, `entryCase` and `case_`  namings are inconsistent.
They also have tuple version, adding the suffix `-T`.
However the tuple version is more commonly used.

Solution: Rename the current `construct`, `entryCase` and `case_`
adding suffix `-Rec` instead.
Rename the old tuple version, using simplest name instead.

Problem: To resemble more other imperative languages,
it would be nice to rename `newVar` to a shorter word and add infix operator for `setVar`

Solution: Rename `newVar` to just `new` and add `(=:)` as infix operator for `setVar`

Problem: somehow hpack decided to set `cabal-version` to 2.0 and
now `indigo` fails the check for common mistakes:
```
Package check reported the following errors:
The package uses RebindableSyntax with OverloadedStrings or
OverloadedLists in default-extensions, and also Paths_ autogen module.
That configuration is known to cause compile failures with Cabal < 2.2.
To use these default-extensions with Paths_ autogen module specify at
least 'cabal-version: 2.2'.
```

Solution: in order to avoid such errors we explicitly require
cabal-version to be 2.2.

Problem: we recently updated license that applies to all files.
Now it's MIT. But Haskell packages still say it's AGPL.
Solution: update `LICENSE` files and `license` fields.

Problem: recently gitlab changed the way URLs are formed, specifically:
1. There is `/-/` in many URLs such as
https://gitlab.com/morley-framework/morley/-/issues.
2. Because of that some relative links like `../blob/foo` are broken.
3. And of course many links are a bit obsolete because they get
redirected.

Solution:
1. Apparently now we can use saner links in MR templates, e. g.
just `README.md` instead of `../blob/master/README.md`. So we do it.
2. Obsolete links are updated to include this `/-` thing.

Problem: it is not always clear what constructors and/or fields of ADTs
used in contract mean, but there is now way to document them except of
using `typeDocMdDescription`, which is not checked by the compiler.

Solution: add type-level descriptions for constructors and fields.
Demand that those descriptions are attached only to existing
constructors and fields, via a type family.

* Add licenses for everything
* Almost everything is copyrighted by TQ and the license is MIT,
* apart from some dot-files in the root (Unlicensed by Serokell)
* and example contracts comming from Tezos.

Problem: Indigo has `makeView` expression to create `View` but none to
create `Void_`

Solution: Add `makeVoid` expression to create `Void_`

Problem: type signatures or annotations always need to be specified for
numeric values in Indigo code, because they are otherwise ambiguous.
However, Indigo uses `RebindableSyntax` that allows to define a
`fromInteger` function used to resolve numeric literals, and this can
be used to implement (some) custom resolution logic.

Solution: implement a `fromInteger` that takes an additional value
(beside the Integer) that provides disambiguation for the resulting
value type, with function constructors for this type that match the
target Michelson type.
Additionally, because of this, the 'int' expression has been renamed
'toInt'.

Problem: (!~) operator exists for `Name` expression, but no operator exists for `UnName`.

Solution: Add `UnName` operator (!!~), and replace existing `UnName` with the new operator.

Problem: `xor` is the only operation in `Bits and boolean` that is not an infix operator.

Solution: Replace `xor` with infix operator (^.).

Problem: The chapters of the Indigo tutorial refer to appendices that
are empty regarding types and expressions.

Solution: add content to both appendices (and complete the tutorial).

Problem: In indigo we have expressions that refer to haskell `Maybe`
types such as `ifJust` which is inconvient since we use constructors
such as `some` and `none` that refer to Michelson types and so such
occurences need to be renamed.

Solution: Rename `ifJust` and `ifNothing` to `ifSome` and `ifNone`.

Problem: it's not possible to use newly written machinery
in statements like 'setVar' and 'setField'.

Solution: first of all we need to implement decomposition functionality:
when we assign a var new value, this variable might be decomposed,
so we need to decompose our value to and call 'setVar' recursively.
This functionality is implemented in 'Expr.Decompose'.
Secondly, before compile contract we need to fully decompose
storage into cells, to have at least one decomposed variable to
see the effect of implemented approach.

Problem: some lambas may modify storage, some may not,
and depending on that the amount of code which is generated
can be reduced.

Solution: introduce three types of lambda with one argument:
* pure lambdas (which don't modify neither storage nor operations)
* regular lambas (which modify storage)
* lambda with effects (which modify storage and operations)

Problem: Indigo tutorial has not been fully checked since recent
changes and there are some small mistakes, additionally the modules
it references also have some imperfections in their docs.

Solution: The tutorial was rechecked agaist the current implementation
and the docs have been rephrased/adjusted.
Additionally some code-style fixes have been made in these modules.

Problem: `cabal check` reports a warning for `indigo-tutorial`
because its description is not longer than its synopsis.
We don't really care about that because this package is only for
CI, but for other packages we want `cabal check` to pass with no
warnings and it's easier to fix `indigo-tutorial` than to ignore it.

Solution: expand the description.

Problem: it's 2020 already and GHC-8.8 is out, but we still use 8.6
branch.

Solution: use LTS-15.7 with GHC-8.8.3. Support newer `singletons`. Clean
all new warnings.
Co-authored-by: Maxim Koltsov <kolmax94@gmail.com>

Problem: Indigo's tutorial does not actually build, because its
example modules are not included in the cabal file.
This was caused by the modules having thir name starting with a
number instead of a capital letter.
Additionally, recent updates have broken these modules so they
would not compile anyway.

Solution: rename modules to include them in the cabal file, fix what
was broken by recent changes.

Problem: after the structure of the code has been changed,
some information in tutorial is outdated. Also, ther is no chapter
about introduced Program freer monad.

Solution: add chapter about freer monad, correct some places of the tutorial,
fix broken links to modules.

Problem: Indigo documentation is outdated and was written for internal
use only. It would be better to have a newcomers-frienly tutorial that
also introduces concepts for developers.

Solution: create a tutorial with examples that is easy to follow and
contains (updated) information from the old README.
Provide then a simpler README that refers to the tutorial.
Additionally, add printing and type synonyms that help Indigo usage.