1. 25 Jun, 2020 1 commit
    • Moremi Vannak's avatar
      [#69] Replace `Wrapped` with custom typeclass that allows `deriving anyclass` · f8b5f146
      Moremi Vannak authored
      Problem: `Wrapped` is a thing from `lens` which allows understanding newtype content.
      It would be nice to replace it with a custom typeclass for a couple of reasons:
      1. `Wrapped` cannot be used within `deriving anyclass` clause, one has to declare a
      standalone instance, and if we make a copy of `Wrapped` with the type family but without
      methods, then the problem will be resolved.
      2. Our custom typeclass can be documented, it would be nice to have exact use cases for it
      Solution:  Replace `Wrapped` with custom typeclass that is the same as
      `Wrapped` without its method.
  2. 15 May, 2020 1 commit
    • Kirill Elagin's avatar
      Add licensing information · 1776886c
      Kirill Elagin authored
      * 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.
  3. 29 Apr, 2020 1 commit
    • Sandeep.C.R's avatar
      [#22] Make pairs comparable and available in sets and as map keys. · 90a2d6c2
      Sandeep.C.R authored
      Problem: Comparability of pairs was added in the Babylon protocol. But
      in Morley, pairs are still not comparable. And only comparable types are
      represented by `CT` type. We must make pairs comparable and also allow
      use of comparable pairs in sets and as map keys, where any comparable
      types could appear.
      Solution: Flatten the `T` type by integrating `CT` type into it. This
      demands a way to mark `T` values that are valid as per Michelson.
      Because we no longer have a type dedicated to hold comparable types.
      For this a `WellTyped` class was added which specifies and enforces the
      typing rule w.r.t comparablilty as prescribed by Michelson.
      Tests: Two test contracts were added. One that has a
      `set (pair int int)` as parameter, which we expect to be parsed and pass
      typecheck. The other one with a `set (pair unit unit)` which we expect
      to be rejected.
      [#22] Update changelog
  4. 14 Apr, 2020 1 commit
  5. 24 Feb, 2020 3 commits
    • Konstantin Ivanov's avatar
      [#89] Describe `CanCastTo` better · c892b05d
      Konstantin Ivanov authored
      Problem: use cases for `CanCastTo` are not clear.
      Solution: write them down.
    • Konstantin Ivanov's avatar
      [#89] Add `CanCastTo` helpers for complex types · 68da26f4
      Konstantin Ivanov authored
      Problem: for `CanCastTo` instances for complex types we do not ensure
      that all necessary constraints are enlisted in superclass. This may lead
      to writting an unsafe code.
      Solution: allow one specify implementation of `CanCastTo`'s only method
      which would ensure via Generics that constraints on all types which
      given type consists of are enlisted.
    • Konstantin Ivanov's avatar
      [#89] Add more `CanCastTo` instances · 4fa6aa4e
      Konstantin Ivanov authored
      Problem: we have `CanCastTo` instances only for few random types, it
      would be nice to have it at least for all Michelson primitives and our
      macro types like View.
      Solution: add instances.
  6. 19 Feb, 2020 3 commits
    • Ivan Gromakovskii's avatar
      [TM-309] Rename `morley-lorentz` to `lorentz` · 2b6b7ec6
      Ivan Gromakovskii authored
      Problem: we had a poll across developers and decided to rename
      `morley-lorentz` to simply `lorentz`.
      It does not have good argument, just some bikeshedding.
      Solution: rename everywhere.
    • Ivan Gromakovskii's avatar
      [TM-309] Move almost all packages into `code/` · 24c0f4e1
      Ivan Gromakovskii authored
      Problem: now that we have many packages in the repo, the root
      directory became quite big, it is a bit hard to see what is there.
      Also the name of `prelude` folder is a bit inconsistent: for other
      packages their folder has the same name as the package, but for
      `morley-prelude` it does not hold.
      1. Move all packages except for `morley` into `code/` directory.
      The idea is to have all code there and `morley` will be moved in
      the next commit as it is more involved.
      2. Rename `prelude/` folder to `morley-prelude/`.
    • Pinto Pasquale's avatar
      [#97] add Label type that includes `KnownSymbol` constraint · 1cd264e3
      Pinto Pasquale authored
      Problem: we use `Label` from `Vinyl`, but in the vast majority of the
      cases we need the `KnownSymbol` constraint as well.
      Because of this we end needing to specify and carry around this
      constraint in a lot of the functions that operate with `Label`s
      Solution: add a custom `Label` type that includes the `KnownSymbol`
      constraint and remove it from every place possible.
  7. 18 Feb, 2020 1 commit
    • Konstantin Ivanov's avatar
      [TM-280] Extract `TAddress` and stuff to sep module · 572d7c5c
      Konstantin Ivanov authored
      Problem: `Lorentz.Value` is a mess, it would be nice to move all new
      Lorentz types related to entrypoints somewhere.
      Solution: move to `Lorentz.Address`.
      Make some changes in modules dependency graph (from bottom to top):
      * Lorentz.Base
      * Lorentz.Address
      * Lorentz.Value
      * Lorentz.Instr / Lorentz.Coercions
      * ...
      Also fix some typos.
  8. 16 Feb, 2020 1 commit
    • Ivan Gromakovskii's avatar
      [TM-309] Move Lorentz code into a new package · 55db7077
      Ivan Gromakovskii authored
      Over time some `morley` package became bigger and it seems that now
      is a good time to draw some boundaries between its parts.
      The main reason is that if a package contains X and Y while someone
      needs only X, they will be forced to depend on Y as well.
      Also it makes dependencies inside this repo more explicit and clear.
      Solution: create `morley-lorentz` package and move Lorentz code
      I had to move some utility testing code used by Lorentz tests to
      `morley` lib or to `morley-lorentz` (if it is used only
      by `morley-lorentz`).
      Also I moved `tOriginate`, `tTransfer` and `tExpectStorageConst` to
      `Michelson.Test.Integrational` because they do not use anything
      from Lorentz.
      Some difficulties arose because some tests in `morley` use Lorentz.
      They were solved as follows:
      1. `Test.Integrational` was rewritten using Michelson.Typed instead of
      2. `Doc.hs` and `DocTest.hs` tests were moved to `morley-lorentz`
      because they are heavily based on Lorentz. Also `Lorentz.*` tests were
      moved there.
      3. `Test.Interpreter` was split into two `Test.Interpreter` modules
      (in different test-suites). In the next commit we will clean it up.
      Another notable change is movement of Arbitrary instances for UStore
      types into UStore.Types module. As a bonus it removed 2 orphan
  9. 30 Jan, 2020 1 commit
    • Konstantin Ivanov's avatar
      Add permanent entrypoints to upgradeable contract · c1d3591b
      Konstantin Ivanov authored
      Problem: we need upgradeable contract to implement arbitrary interfaces
      like FA1.2 which are not aware about our special parameter passing.
      For such interfaces we need a way to add normal entrypoints which can be
      called by name.
      Solution: add another type family to `KnownContractVersion` which
      designates a subparameter corresponding to permanent entrypoints.
      This may be a bit counter-intuitive since permanent entrypoints are the
      same for all versions of a contract, but that seems to be the simplest
      way from UX point of view. The mentioned fact is ensured at migration
      building stage, one won't be able to construct an upgrade if
      participating contract versions differ in their permanent parameter.
      Then we add:
      * Entrypoint for running permanent entrypoints;
      * Implementation of permanent entrypoints in storage;
      * Add/modify entrypoints to make it possible to update permanent
        entrypoints implementation (as storage changes, we may need to change
        the implementation).
  10. 22 Jan, 2020 2 commits
    • Konstantin Ivanov's avatar
      [TM-280] Make `FutureContract` proper · 384a0f0f
      Konstantin Ivanov authored
      Problem: we can't implement `embodyFutureContract` because we lose the
      nessary information about the entire parameter of the contract at the
      moment of having only `FutureContract`.
      Solution: we leave the main purpose of this type to be mimicking
      Michelson's 'contract' type while in fact being typed 'address' which
      can be used everywhere.
      It seems like there is no way to implement this thing entirely safely
      because in Haskell world it needs to remember full coordinates of a
      particular entrypoint (either address + type-level parameter and name,
      or address and way to lift entrypoint argument to the full parameter as
      'ContractRef' does).
      As the least evil in this commit we made it a wrapper over
      'ContractRef', as result it is possible to push this value but fetching
      it back from Michelson to Haskell is not allowed (because knowing only
      address and entrypoint name is not enough to safely recover
      This type is not used anywhere for now, so I'm not sure which
      functions do we need to work with it. But I hope use cases will appear
      someday, if not, let's remove this type completely.
    • Konstantin Ivanov's avatar
      [TM-280] Introduce `TAddress` · cc0f07d6
      Konstantin Ivanov authored
      Problem: currently in integrational tests we use `ContractRef`
      extensively - contract origination returns it and then we pass it to
      transfer function.
      But such its usage is not proper. `ContractRef` corresponds to
      Michelson's `contract` type and refers to a particular entrypoint of the
      contract. But we use it as if it referred only to the contract itself -
      both from `lOriginate` and `lCallEP`'s point of view.
      Solution: we don't yet have a type with mentioned characteristics, let's
      make a new one.
      So we added `TAddress` type which is similar to `Address` but remembers
      type of contract parameter.
      We modified integrational testing primitives accordingly, and added
      `ToTAddress` typeclass which is similar to the previously used
      Now call of `mkView` calls the default entrypoint as expected, not
      always the root one, so now in some test suites parameter of consumer
      contract could not be infered anymore - we annotated them with parameter
      type applications.
  11. 21 Jan, 2020 3 commits
    • Konstantin Ivanov's avatar
      [TM-337] Add incoherent refl `CanCastTo` instance · 6ca63111
      Konstantin Ivanov authored
      Motivation: we can't define `CanCastTo a a` with `OVERLAPPING` pragma
      because that is not enough: on attempt to resolve `CanCastTo (UStore
      template) UStore_` both `instance CanCastTo a a` and `instance CanCastTo
      (UStore t1) (UStore t2)` potentially match.
      And, obviously, `CanCastTo a a` is too often useful for not adding it.
      Actually, using `INCOHERENT` pragma is enough, and should be safe in
      this case.
    • Konstantin Ivanov's avatar
      [TM-337] Set explicit type args in wrap coercions · db8b1bde
      Konstantin Ivanov authored
      Problem: in `coerceWrap` and `coerceUnwrap` one may want to specify both
      newtype and its inner representation as type arguments - for clarity.
      Solution: add explicit forall with the corresponding type arguments.
    • Konstantin Ivanov's avatar
      [TM-337] Add type-safe coercions · 2efba957
      Konstantin Ivanov authored
      Problem: we need a function which can cast e.g.
      `MigrationScriptFrom oldStore` to `MigrationScript oldStore newStore`
      but would prohibit casting if old stores mismatch.
      Using dedicated functions like `unFromMigrationScript` is a vain which,
      probably, no one will use (because using `coerce` is simpler).
      And the current `coerce` is too permissive, using it would ruin
      type-safety of the whole migration framework.
      Solution: add a coercion method where one explicitly specifies casting
      rules via a simple `CanCastTo a b` typeclass.
      Existing `coerce_` is renamed to `forcedCoerce_`, a comment left which
      discourages using this function.
      This commit also describes (in code) an alternative solution via GHC's
      `Coercible` typeclass, though we failed to apply it to our case.
  12. 17 Dec, 2019 1 commit
    • Konstantin Ivanov's avatar
      [TM-358] Fix `fakeCoerce` · fa5a82ae
      Konstantin Ivanov authored
      Problem: this function is assumed to be used in the middle of contract
      code, but with the recent changes we make it truncate everything what
      goes after it.
      Solution: use `I FAILWITH` in `fakeCoerce` instead of implicit `FI
  13. 17 Nov, 2019 1 commit
    • Konstantin Ivanov's avatar
      [TM-280] Introduce entrypoints to Morley · dcfe72e9
      Konstantin Ivanov authored and Konstantin Ivanov's avatar Konstantin Ivanov committed
      Problem: Babylon has lightweight entrypoints feature, we want to support
      Solution: add basic machinery for defining and looking up for
      entrypoints in Morley (for Lorentz they are not yet implemented).
      Cover all missing subfeatures with `TODO`s.
  14. 31 Oct, 2019 1 commit
  15. 23 Oct, 2019 1 commit
    • Konstantin Ivanov's avatar
      [TM-337] Add `interface` type arg to `ContractCode` · dbd49202
      Konstantin Ivanov authored
      Problem: it's possible to accidentially apply contract code with wrong
      set of entrypoints, would be nice to try to keep it polymorphic over
      `entrypoints :: [EntryPointKind]`.
      Solution: make it polymorphic.
      I don't make storage polymorphic over `entrypoints` yet because this
      does not seem to add type-safety yet, and probably making storage
      know about code is better to be avoided until necessary.
  16. 17 Oct, 2019 1 commit
    • Konstantin Ivanov's avatar
      [TM-317] Forbid `contract` type in relevant scopes · 8e4e17de
      Konstantin Ivanov authored
      Problem: in babylon this type cannot be part of storage type or
      constant. Also it's not possible to unpack to something with `contract`
      As experiments have shown, it's still possible to accepts `contract`
      as parameter, as well as pack it.
      The only ways to get a value of type `contract` seems to be `CONTRACT`
      instruction and receiving as parameter.
      Solution: add a constraint similar to `HasNoOp`.
      Propagate this constraint to `StorageScope`, `ConstantScope` and
      `UnpackedValScope` (note that now we have to separate `PackedValScope`
      and `UnpackedValScope`).
      Some contracts had `View` in `UParam` which is now not allowed (because
      `UParam` works via unpacking), it seemed the simplest to make them
      return `Void`.
  17. 29 Jul, 2019 1 commit
  18. 06 Jun, 2019 1 commit
    • Konstantin Ivanov's avatar
      [TM-184] Implement more parts of token · 56317a31
      Konstantin Ivanov authored
      In particular:
      * Pauses
      * `transfer` instruction
      * Take roles into account
      * Keep balances both for wallets and investors
      Unimplemented pieces are marked with `TODO`, and are left for the next
      MR. Currently both complection of registry service and TM-213 need
      what has been done in this commit.
  19. 29 May, 2019 1 commit