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: indigo's homepage (stated in `indigo.cabal`) is
the `morley` repo, but now we have a dedicated website which is
more appropriate.

Solution: override it in `package.yaml`. It complains about duplicated
field, but handles it correctly, so I hope it's fine (better than
copy-pasting or doing some verbose tricks).

Problem: we want to release indigo to Hackage to make it more
accessible.
Solution: prepare for that by adding a changelog and Hackage badge.

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: `assertRight` and `assertLeft` has type equal constraint on
left and right even though there are not necessarily equal.

Solution: Remove the type equal constraint.

Problem: There seems to be no case of `IsExpr ex a` where
`KnownValue a`  constitutes a problem, however we are
required add the latter every time we use the former
(where a is generic).

Solution:  Include `KnownValue a` into `IsExpr ex a`
and remove unnecessary use of `KnownValue`.

Problem: code in Indigo tests needs to be updated, but with the new
update there are many more names conflicts than before.

Solution: split Indigo code from test machinery and update them.

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: In `Indigo.Internal.Object` we have both `IsObject` and
`IsObjectClass`, the latter being a class & instance redefinition
of the former (to allow partial application).

However `IsObject` itself could be written as a class & instance of
`IsObject' (TypeDecision a) a` so there is no need to have both of
them.

Solution: Remove `IsObjectClass` and define `IsObject a` as a class
and instance of `IsObject' (TypeDecision a) a`.

Problem: in several places it would be nice to have opportunity to
compare `Value`s without knowning that their types match.
It should be possible since `Value` is GADT.

Use cases for such comparison:
* Inspecting stacks in tests;
* Displaying stack diffs to user (if found appropriate doing it this
  way);
* Implementing proper `Eq Instr`
  (this is not possible without implementing a
  `Instr i1 o1 -> Instr i2 o2 -> Bool` comparison because of `Seq`s).

Solution: we can implement such comparison if for each `Value t` we can
derive `Dict (Typeable t)`, this would allow us to check whether types
of two `Value`'s match and then comparing them on `==`.

So here we implement `valueTypeSanity` function which performs this
derivation (and `SingI t` for company).
It required adding `Typeable t` and `SingI t` constraints to `Value`'s
list-like constructors, because otherwise someone could construct
`VList [] :: Value Any` which we now have to prohibit.
These new constraints required several changes in
`Michelson.Typed.Instr` and `Michelson.Interpret` modules; also I had to
add those constraints to superclass of `WellTyped` so that they apply to
Lorentz types.

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`.

Problem: `uMem`, `uUpdate`, `uDelete` have not been
ported to Indigo from Lorentz yet.

Solution: Add `uMem`, `uUpdate`, `uDelete` to Indigo.

Indigo

Problem: `assertSome`, `assertNone`, `assertLeft`, `assertRight` has not been
ported to Indigo from Lorentz yet.

Solution: Add `assertSome`, `assertNone`, `assertLeft`, `assertRight` to Indigo.

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: It is tedious to regenerate golden tests in Indigo
when the code generation has been slightly changed.

Solution: Add a way to generate golden tests automatically.

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 we have a wide plethora of operators that follow
the same logic for manipulating different structures that could be
generalized. Specifically we would like to generalize `update`,
`lookup`, `empty`, 'insert`, `remove` instructions for `Set`,
`Map` and `BigMap` types.

Solution: As a solution to this problem we have added a couple
of type classes and operators that help us to define logic for
different structures individually.

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 run tests with `-N` and default options for GC. It is known
that by default GHC's GC has a very small allocation area, meaning that
GCs will occur too often, damaging test's run time.

Solution: increase allocation area by using the recommended `-A64m`
option. Also increase allocation area for large objects with `-AL256m`,
since this area is shared between all threads and thus with high `-N`
values get used up too soon. Also enable `-eventlog` just in case we
need to debug test performance in the future.

Problem: Current `concat`  type signature is incorrect,
since it is not needed for `exN` to be the same.

Solution: Separate `exN` into `exN1` and `exN2` which
are both `IsExpr` of `n`.

Problem: In Lorentz we have an Lorentz.Polymorphic module that contains
both of the polymorphic constraints and their instances.
However to use them in Indigo Expressions, we need to add
additional constraints every time.

Solution: This can be simplified by collecting all the polymorphic constraints
in one place in Indigo.Internal.Expr.Types.

Problem: In Lorentz we have an Lorentz.Arith module that contains
both of the arithmetic constraints and their instances.
However to use them in Indigo Expressions, we need to add
additional constraints every time.

Solution: This can be simplified by collecting all the arithmetic
constraints in one place in `Indigo.Internal.Expr.Types`.

Problem: In Indigo we have the `TypeValue a` constraint that is simply
`Typeable a` and `Typeable (ToT a)`.
However we sometimes have to use this with `KnownValue a` (or one of the
constraints that include it) that already includes `Typeable (ToT a)`.

Solution: Include `Typeable a` in `KnownValue a` and replace `TypeValue`
and `TypeValueClass` with `KnownValue`.

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: `Indigo.Prelude` was originally used to define all the
hiding rules in one place and then to be imported within Indigo.
However, we also export as part of `Indigo` module which then
creating conflicts due to we re-using the same function names
and syntax to write Indigo contract.

Solution: Split current `Indigo.Prelude` into two.
`Indigo.Backend.Prelude` which is used like it original purpose.
New `Indigo.Prelude` which should be used as Export to write
Indigo contract.

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.