LIGO can work together with other smart contract languages on Tezos. However data structures might have different representations in Michelson and not correctly match the standard LIGO types.
Michelson types and annotations
Michelson types consist of
pair's, combined with field annotations.
Field annotations add contraints on a Michelson type, for example a pair of
(pair (int %foo) (string %bar)) will only work with the exact equivalence or
the same type without the field annotations.
works not with
works not with
In the case of annotated entrypoints - the annotated
or tree directly under
parameter in a contract - you should use annotations, as otherwise it's
unclear which entrypoint you are referring to.
Default LIGO output
By default LIGO translates its datatypes into a alphabetically left balanced tree. So, for example:
will translate to:
Right combed tree output
If you want to change the data representation in Michelson to a location retaining right combed tree, like this:
you can use the
layout:comb attribute can also be used on record types:
Different Michelson annotations
If the Michelson annotation should be different from the LIGO representation,
annot:<string> attribute can be used. For example:
will result into:
annot:<string> attribute can also be used on record field annotations:
annot:<string> attributes are not adequate enough
for your use case, LIGO has more advanced advanced interop features which we
will we discuss next.
Advanced interop with Michelson
To interop with existing Michelson code or for compatibility with certain
development tooling, LIGO has two special interop types:
michelson_pair. These types give the flexibility to model the exact Michelson
output, including field annotations.
Take for example the following Michelson type that we want to interop with:
To reproduce this type we can use the following LIGO code:
If you don't want to have an annotation, you need to provide an empty string.
Alternatively, if annotations are not important you can also use plain tuples for pair's instead. Plain tuples don't have any annotations.
To use variables of type
michelson_or you have to use
M_left picks the left
or case while
M_right picks the right
michelson_pair you need to use tuples.
Converting between different LIGO types and data structures can happen in two ways. The first way is to use the provided layout conversion functions, and the second way is to handle the layout conversion manually.
In all cases it will increase the size of the smart contract and the conversion will happen when running the smart contract.
Converting left combed Michelson data structures
Here's an example of a left combed Michelson data structure using pairs:
Which could respond with the following record type:
If we want to convert from the Michelson type to our record type and vice versa, we can use the following code:
In the case of a left combed Michelson
or data structure, that you want to
translate to a variant, you can use the
And then use these types in
Layout.convert_to_left_comb, similar to the
pairs example above, like this:
Converting right combed Michelson data structures
In the case of right combed data structures, like:
you can almost use the same code as that for the left combed data structures,
Manual data structure conversion
If you want to get your hands dirty, it's also possible to do manual data structure conversion.
The following code can be used as inspiration:
Entrypoints and annotations
It's possible for a contract to have multiple entrypoints, which translates in
LIGO to a
parameter with a variant type as shown here:
This contract can be called by another contract, like this one:
Notice how we directly use the
%left entrypoint without mentioning the
%right entrypoint. This is done with the help of annotations. Without
annotations it wouldn't be clear what our
int would be referring to.
This currently only works for
or's or variant types in LIGO.
With the upcoming 007 amendment to Tezos this will change though, and also
pair's can be ordered differently.