1. 19 Jun, 2020 4 commits
    • Pinto Pasquale's avatar
      [TM-410] make Indigo's tutorial a buildable website · 9f3d3d66
      Pinto Pasquale authored
      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
    • Pinto Pasquale's avatar
      [TM-410] re-arrange indigo tutorial's files for website building · 1145fb98
      Pinto Pasquale authored
      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.
    • Ivan Gromakovskii's avatar
      Override indigo's homepage · 99c0d9ab
      Ivan Gromakovskii authored
      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).
    • Ivan Gromakovskii's avatar
      [Chore] Prepare indigo release · 3e39afc9
      Ivan Gromakovskii authored
      Problem: we want to release indigo to Hackage to make it more
      Solution: prepare for that by adding a changelog and Hackage badge.
  2. 15 Jun, 2020 1 commit
    • Anton Myasnikov's avatar
      [#177] Make 'contractCallingUnsafe' easier to use · 55505f3a
      Anton Myasnikov authored
      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.
  3. 12 Jun, 2020 2 commits
    • Moremi Vannak's avatar
      [#237] Remove equality constraint in `assertRight` and `assertLeft` · e03e69de
      Moremi Vannak authored
      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.
    • Moremi Vannak's avatar
      [#237] Include `KnownValue` into `IsExpr` · 453095e5
      Moremi Vannak authored
      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`.
  4. 09 Jun, 2020 4 commits
    • Pinto Pasquale's avatar
      [#124] update Indigo tests and split modules · 1ebf5682
      Pinto Pasquale authored
      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.
    • Pinto Pasquale's avatar
      [#124] revise Indigo operators · 8a5a2539
      Pinto Pasquale authored
      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.
    • Moremi Vannak's avatar
      [#221] Use mixins instead of base-noprelude · 07210557
      Moremi Vannak authored
      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.
    • Moremi Vannak's avatar
      [#226] Merge `IsObject` and `IsObjectClass` · 84b9d51c
      Moremi Vannak authored
      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
      Solution: Remove `IsObjectClass` and define `IsObject a` as a class
      and instance of `IsObject' (TypeDecision a) a`.
  5. 04 Jun, 2020 1 commit
    • Konstantin Ivanov's avatar
      [#93] Implement extended `==` on `Value` · 68da7a97
      Konstantin Ivanov authored
      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
      * 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.
  6. 03 Jun, 2020 7 commits
  7. 01 Jun, 2020 3 commits
    • Anton Myasnikov's avatar
      [#168] Remove TODO from indigo tutorial regarding overloaded lists · d1206f08
      Anton Myasnikov authored
      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
      Solution: Remove a TODO from the second appendix of indigo tutorial.
    • Anton Myasnikov's avatar
      [#173] Update tutorial · e174f7d2
      Anton Myasnikov authored
    • Anton Myasnikov's avatar
      [#173] Generalize structure-manipulation indigo expressions · 87e18288
      Anton Myasnikov authored
      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.
  8. 30 May, 2020 1 commit
    • Maxim Koltsov's avatar
      [TM-62] Do address computation more correctly · 70388829
      Maxim Koltsov authored
      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
  9. 29 May, 2020 5 commits
    • Diogo Castro's avatar
    • Maxim Koltsov's avatar
      Tune GC RTS options for tests · a4cdd3af
      Maxim Koltsov authored
      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.
    • Moremi Vannak's avatar
      [#228] Fix type signature for `concat` Indigo · 0967ccd4
      Moremi Vannak authored
      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`.
    • Moremi Vannak's avatar
      [#228] Add polymorphic constraints to Indigo Expr · 4ffcc37a
      Moremi Vannak authored
      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.
    • Moremi Vannak's avatar
      [#224] Add arithmetic constraints to Indigo Expr · 43e5004a
      Moremi Vannak authored
      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`.
  10. 27 May, 2020 1 commit
    • Moremi Vannak's avatar
      [#225] Update KnownValue in Lorentz and use it in Indigo instead of TypeValue · 3ba96d12
      Moremi Vannak authored
      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`.
  11. 25 May, 2020 1 commit
  12. 22 May, 2020 3 commits
    • Moremi Vannak's avatar
      [#217] - Add `nonZero` to Indigo expression · 825f6432
      Moremi Vannak authored
      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
    • Moremi Vannak's avatar
      [#138] Reduce the usage `$` in Indigo · 89ae9d78
      Moremi Vannak authored
      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
    • Moremi Vannak's avatar
      [#206] Split `Indigo.Prelude` into 2 modules · c33b6891
      Moremi Vannak authored
      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.
  13. 21 May, 2020 3 commits
    • Moremi Vannak's avatar
      [#175] Remove TODO related to `xor` · 0f7ebb99
      Moremi Vannak authored
      Problem: There is a TODO comment related to `xor` issue that is not removed.
      Solution: Remove the TODO comment.
    • Moremi Vannak's avatar
      [#176] Rename `concat'` expression in Indigo · bff9757b
      Moremi Vannak authored
      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`
    • Moremi Vannak's avatar
      [#204] Fix the Indigo tutorial REPL command · 6cc9ddec
      Moremi Vannak authored
      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`.
  14. 20 May, 2020 2 commits
  15. 19 May, 2020 2 commits
    • Ivan Gromakovskii's avatar
      Require cabal-version to be 2.2 · 6be834a4
      Ivan Gromakovskii authored
      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.
    • Ivan Gromakovskii's avatar
      Update license information in Haskell packages · 9754db3a
      Ivan Gromakovskii authored
      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.