Porting to Ligo: a gradual transition strategy

[purcell]

Goals

• Be able to write ocaml and use the normal devtools there (merlin, ocamllsp, test frameworks)
• Don't have two separate codebases where we have to duplicate the same change in both manually
• Keep tests running as we change the code's shape to match Ligo
• Preserve comment documentation in context / use ocamldoc to document the contract?

Proposed approach

Write Ocaml that approaches Ligo, with shims

Code that is to be included in the target contract is written in Ocaml, in a particular style:

• No modules (for now, because of uncurrying in ligo), instead just write regular mli and ml files (mli files ignored for ligo purposes)
• Only tail recursion
• Avoid .foo accesses, which can lead to multiple unpacking of data (citation needed!)
• Caution with nested pattern matching (currently, but okay soon)
• No _ as an identifier or wildcard in patterns, avoid ' suffixes
• Monomorphic types, specify types for polymorphic functions
• Avoid ~keyword args
• To use other modules, always "open" them
• Give all functions type signatures
• Give all functions globally-unique names, e.g. ratio_add instead of add
• Mark ocaml-only code with preprocessor directives that our tool can recognise
• Rely only on core types and operators from Ligo module, e.g. int, big_map, list, mutez, with that module corresponding to the "top-level" module in Ligo itself.
• For other Ligo API modules, use LigoBig_map, LigoString, LigoList, LigoMap, LigoTezos etc., and qualify the names fully (we will write whichever of these modules we need to use). See https://ligolang.org/docs/reference/current-reference
• Ligo will have some differences to Ligo's actual stdlib:
  • ediv_mutez_nat etc. instead of ediv variants
  • failwith variants
  • add_nat_mutez etc. for basic arithmetic
  • assert variant with a different name, string param
• The LigoXXX modules may expose some functions that facilitate testing, e.g. unwrap Ligo lists/strings as the ocaml equivalents, or set the active balance for LigoTezos.

Process for translation to Ligo

As an automated process, produce Ligo from Ocaml and build it with the Ligo tools, following these conversion steps:

• Replace open with #include
• Remove Ligo. prefix for qualified identifiers
• Remove Ligo prefix for remaining qualified identifiers, ie. LigoString.foo => String.foo
• Strip out code marked as ocaml-only (but try to keep line count the same by inserting blanks so that line numbers for errors stay the same)
• Unwrap any commented @inline directives meant for Ligo (and, in general, any code somehow marked as "ligo only", if we do that)
• Replace ediv_xxx variants with just ediv
• Replace failwith variants with just failwith
• Provide @inline-d arithmetic functions that just defer to builtins
• Potentially more stuff later about limiting contract code size, putting code in lambdas if necessary

Initial code changes necessary:

• Write Ratio/FixedPoint/Tez/Nat in terms of Ligo module's types, or remove entirely as appropriate
• AVL may retain special translation rules to allow polymorphism, or potentially more extensive "only ocaml" and "only ligo" conditional code
• Checker top-level becomes structured in terms of Ligo entrypoints and their typical API, returning "operations", so tests will have to change correspondingly.
• Stop passing instances of our Tezos as a param, instead mutate LigoTezos globals using ocaml-only backdoor functions provided for testing purposes, e.g. to change now

[murbard]

This sounds sensible. You missed two important ones IMO :

• decurryfy all functions
• do not use continuations to make functions tail recursive, use an explicit data structure instead like a list representing the argument stack

[purcell]

* decurryfy all functions

There's actually a Ligo merge request in the works that makes this unnecessary, at least as long as code isn't explicitly placed in modules (which are now preliminarily supported), so we've taken this into account in our planning.

[utdemir]

do not use continuations to make functions tail recursive, use an explicit data structure instead like a list representing the argument stack

And we already have followed this through, sorry I forgot to post an update to the channel. Now we don't use continuations on avl. I remember that change saving around 25% of generated Michelson.

[purcell]

Open issue: Ligo has no mechanism for originating a new contract, yet Checker will need to originate Burrow contracts. How will we do this? Presumably we will drop down to michelson for this.

[purcell]

To do next:

• [x] Don't require delegate hash when bidding in delegate auction, just when claiming the win (Steve)
• [x] Switch checker endpoints that return payments to instead return operations using Tezos.transaction
• [x] Provide origination for burrow contracts, via undocumented Tezos.create_contract (see here)
• [x] Make the top-level of checker work idiomatically with a main and a sum type of entrypoints (see here) - maybe do this early to see more generated Michelson earlier

[gkaracha]

make build-ligo now succeeds with all entrypoints being reachable, so I think we can safely close this one.