balsoft/ligo
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Merge branch 'dev' into docs/map-reference

Browse Source
This commit is contained in:
John David Pressman 2020-02-10 20:53:30 -08:00
commit bfd240dacf
417 changed files with 69429 additions and 8236 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
.gitignore vendored
View File

@ -5,9 +5,11 @@ cache/*
Version.ml
/_opam/
/*.pp.ligo
/*.pp.mligo
/*.pp.religo
**/.DS_Store
.vscode/
/ligo.install
*.coverage
/_coverage/
/_coverage_*/
/_coverage_*/

25
.gitlab-ci.yml
View File

@ -3,9 +3,11 @@ variables:
GIT_SUBMODULE_STRATEGY: recursive
build_binary_script: "./scripts/distribution/generic/build.sh"
package_binary_script: "./scripts/distribution/generic/package.sh"
LIGO_REGISTRY_IMAGE_BASE_NAME: "${CI_PROJECT_PATH}/${CI_PROJECT_NAME}"
stages:
- test
- ide
- build_and_package_binaries
- build_docker
- build_and_deploy_docker
@ -38,6 +40,7 @@ dont-merge-to-master:
- build-and-package-ubuntu-18-04
- build-and-package-ubuntu-19-04
before_script:
- export TERM=dumb
- scripts/install_native_dependencies.sh
- scripts/install_opam.sh # TODO: or scripts/install_build_environment.sh ?
- export PATH="/usr/local/bin${PATH:+:}${PATH:-}"
@ -75,15 +78,16 @@ dont-merge-to-master:
- public
.docker: &docker
image: docker:1.11
image: docker:19
services:
- docker:dind
- docker:19-dind
.before_script: &before_script
before_script:
# Install dependencies
# rsync is needed by opam to sync a package installed from a local directory with the copy in ~/.opam
- export TERM=dumb
- scripts/install_native_dependencies.sh
- scripts/install_opam.sh # TODO: or scripts/install_build_environment.sh ?
- export PATH="/usr/local/bin${PATH:+:}${PATH:-}"
@ -130,7 +134,7 @@ build-and-publish-latest-docker-image:
- sh scripts/build_docker_image.sh
- sh scripts/test_cli.sh
- docker login -u $LIGO_REGISTRY_USER -p $LIGO_REGISTRY_PASSWORD
- docker push $LIGO_REGISTRY_IMAGE:next
- docker push ${LIGO_REGISTRY_IMAGE_BUILD:-ligolang/ligo}:next
only:
- dev
@ -140,7 +144,7 @@ build-and-package-debian-9:
<<: *docker
# To run in sequence and save CPU usage, use stage: build_and_package_binaries
stage: test
variables:
variables:
target_os_family: "debian"
target_os: "debian"
target_os_version: "9"
@ -152,7 +156,7 @@ build-and-package-debian-10:
<<: *docker
# To run in sequence and save CPU usage, use stage: build_and_package_binaries
stage: test
variables:
variables:
target_os_family: "debian"
target_os: "debian"
target_os_version: "10"
@ -168,7 +172,7 @@ build-and-package-ubuntu-18-04:
<<: *docker
# To run in sequence and save CPU usage, use stage: build_and_package_binaries
stage: test
variables:
variables:
target_os_family: "debian"
target_os: "ubuntu"
target_os_version: "18.04"
@ -180,7 +184,7 @@ build-and-package-ubuntu-19-04:
<<: *docker
# To run in sequence and save CPU usage, use stage: build_and_package_binaries
stage: test
variables:
variables:
target_os_family: "debian"
target_os: "ubuntu"
target_os_version: "19.04"
@ -188,6 +192,13 @@ build-and-package-ubuntu-19-04:
only:
- dev
trigger-webide:
stage: ide
trigger:
include: tools/webide/webide-ci.yml
# Pages are deployed from dev, be careful not to override 'next'
# in case something gets merged into 'dev' while releasing.
pages:

2
docker/distribution/generic/build.Dockerfile
View File

@ -29,7 +29,7 @@ RUN opam update
# Install ligo
RUN sh scripts/install_vendors_deps.sh
RUN opam install -y .
RUN opam install -y . || (tail -n +1 ~/.opam/log/* ; false)
# Use the ligo binary as a default command
ENTRYPOINT [ "/home/opam/.opam/4.07/bin/ligo" ]

549
gitlab-pages/docs/advanced/entrypoints-contracts.md
View File

@ -1,173 +1,236 @@
---
id: entrypoints-contracts
title: Entrypoints, Contracts
title: Access function and Entrypoints
---
## Access Functions
A LIGO contract is made of a series of constant and function
declarations. Only functions having a special type can be called when
the contract is activated: we called them *access functions*. An
access function takes two parameters, the *contract parameter* and the
*on-chain storage*, and returns a pair made of a *list of operations*
and a (new) storage.
When the contract is originated, the initial value of the storage is
provided. When an access function is later called, only the parameter
is provided, but the type of an access function contains both.
The type of the contract parameter and the storage are up to the
contract designer, but the type for list operations is not. The return
type of an entrypoint is as follows, assuming that the type `storage`
has been defined elsewhere. (Note that you can use any type with any
name for the storage.)
<!--DOCUSAURUS_CODE_TABS-->
<!--PascaLIGO-->
```pascaligo skip
type storage is ... // Any name, any type
type return is list (operation) * storage
```
<!--CameLIGO-->
```cameligo skip
type storage = ... // Any name, any type
type return = operation list * storage
```
<!--ReasonLIGO-->
```reasonligo skip
type storage = ...; // Any name, any type
type return = (list (operation), storage);
```
<!--END_DOCUSAURUS_CODE_TABS-->
The contract storage can only be modified by activating an access
function. It is important to understand what that means. What it does
*not* mean is that some global variable holding the storage is
modified by the entrypoint. Instead, what it *does* mean is that,
given the state of the storage *on-chain*, an entrypoint specifies how
to create another state for it, depending on a parameter.
Here is an example where the storage is a single natural number that
is updated by the parameter.
<!--DOCUSAURUS_CODE_TABS-->
<!--PascaLIGO-->
```pascaligo group=a
type storage is nat
type return is list (operation) * storage
function save (const parameter : nat; const store : storage) : return is
((nil : list (operation)), parameter)
```
<!--CameLIGO-->
```cameligo group=a
type storage = nat
let save (parameter, store: nat * storage) : return =
(([] : operation list), parameter)
```
<!--ReasonLIGO-->
```reasonligo group=a
type storage = nat;
let main = ((parameter, store): (nat, storage)) : return => {
(([] : list (operation)), parameter);
};
```
<!--END_DOCUSAURUS_CODE_TABS-->
## Entrypoints
Each LIGO smart contract is essentially a single main function, referring to the following types:
In LIGO, the design pattern is to have *one* access function that
dispatches the control flow according to its parameter. Those
functions called for those actions are called *entrypoints*.
As an analogy, in the C programming language, the `main` function is
the unique access function and any function called from it would be an
entrypoint.
The parameter of the contract is then a variant type, and, depending
on the constructors of that type, different functions in the contract
are called. In other terms, the unique access function dispatches the
control flow depending on a *pattern matching* on the contract
parameter.
In the following example, the storage contains a counter of type `nat`
and a name of type `string`. Depending on the parameter of the
contract, either the counter or the name is updated.
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
```pascaligo group=a
type parameter_t is unit
type storage_t is unit
type return_t is (list(operation) * storage_t)
```
<!--CameLIGO-->
```cameligo group=a
type parameter_t = unit
type storage_t = unit
type return_t = (operation list * storage_t)
```
<!--ReasonLIGO-->
```reasonligo group=a
type parameter_t = unit;
type storage_t = unit;
type return_t = (list(operation) , storage_t);
```
<!--END_DOCUSAURUS_CODE_TABS-->
Each main function receives two arguments:
- `parameter` - this is the parameter received in the invocation operation
- `storage` - this is the current (real) on-chain storage value
Storage can only be modified by running the smart contract entrypoint, which is responsible for returning a pair holding a list of operations, and a new storage.
Here is an example of a smart contract main function:
> 💡 The contract below literally does *nothing*
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
```pascaligo group=a
function main(const parameter: parameter_t; const store: storage_t): return_t is
((nil : list(operation)), store)
```
<!--CameLIGO-->
```cameligo group=a
let main (parameter, store: parameter_t * storage_t) : return_t =
(([]: operation list), store)
```
<!--ReasonLIGO-->
```reasonligo group=a
let main = ((parameter, store): (parameter_t, storage_t)) : return_t => {
(([]: list(operation)), store);
};
```
<!--END_DOCUSAURUS_CODE_TABS-->
A contract entrypoints are the constructors of the parameter type (variant) and you must use pattern matching (`case`, `match`, `switch`) on the parameter in order to associate each entrypoint to its corresponding handler.
To access the 'entrypoints' of a contract, we define a main function whose parameter is a variant type with constructors for each entrypoint. This allows us to satisfy the requirement that LIGO contracts always begin execution from the same function. The main function simply takes this variant, pattern matches it to determine which entrypoint to dispatch the call to, then returns the result of executing that entrypoint with the projected arguments.
> The LIGO variant's are compiled to a Michelson annotated tree of union type.
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
```pascaligo group=recordentry
type parameter_t is
| Entrypoint_a of int
| Entrypoint_b of string
type storage_t is unit
type return_t is (list(operation) * storage_t)
function handle_a (const p : int; const store : storage_t) : return_t is
((nil : list(operation)), store)
function handle_b (const p : string; const store : storage_t) : return_t is
((nil : list(operation)), store)
function main(const parameter: parameter_t; const store: storage_t): return_t is
case parameter of
| Entrypoint_a (p) -> handle_a(p,store)
| Entrypoint_b (p) -> handle_b(p,store)
end
```
<!--CameLIGO-->
```cameligo group=recordentry
type parameter_t =
| Entrypoint_a of int
| Entrypoint_b of string
type storage_t = unit
type return_t = (operation list * storage_t)
let handle_a (parameter, store: int * storage_t) : return_t =
(([]: operation list), store)
let handle_b (parameter, store: string * storage_t) : return_t =
(([]: operation list), store)
let main (parameter, store: parameter_t * storage_t) : return_t =
match parameter with
| Entrypoint_a p -> handle_a (p,store)
| Entrypoint_b p -> handle_b (p,store)
```
<!--ReasonLIGO-->
```reasonligo group=recordentry
type parameter_t =
| Entrypoint_a(int)
| Entrypoint_b(string);
type storage_t = unit;
type return_t = (list(operation) , storage_t);
let handle_a = ((parameter, store): (int, storage_t)) : return_t => {
(([]: list(operation)), store); };
let handle_b = ((parameter, store): (string, storage_t)) : return_t => {
(([]: list(operation)), store); };
let main = ((parameter, store): (parameter_t, storage_t)) : return_t => {
switch (parameter) {
| Entrypoint_a(p) => handle_a((p,store))
| Entrypoint_b(p) => handle_b((p,store))
}
};
```
<!--END_DOCUSAURUS_CODE_TABS-->
## Built-in contract variables
Each LIGO smart contract deployed on the Tezos blockchain, has access to certain built-in variables/constants that can be used to determine a range
of useful things. In this section you'll find how those built-ins can be utilized.
### Accepting/declining money in a smart contract
This example shows how `amount` and `failwith` can be used to decline a transaction that sends more tez than `0mutez`.
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
<!--PascaLIGO-->
```pascaligo group=b
function main (const p : unit ; const s : unit) : (list(operation) * unit) is
block {
if amount > 0mutez then failwith("This contract does not accept tez") else skip
} with ((nil : list(operation)), unit);
type parameter is
Entrypoint_A of nat
| Entrypoint_B of string
type storage is record [
counter : nat;
name : string
]
type return is list (operation) * storage
function handle_A (const n : nat; const store : storage) : return is
((nil : list (operation)), store with record [counter = n])
function handle_B (const s : string; const store : storage) : return is
((nil : list (operation)), store with record [name = s])
function main (const param : parameter; const store : storage): return is
case param of
Entrypoint_A (n) -> handle_A (n, store)
| Entrypoint_B (s) -> handle_B (s, store)
end
```
<!--CameLIGO-->
```cameligo group=b
let main (p, s: unit * unit) : operation list * unit =
if amount > 0mutez
then (failwith "This contract does not accept tez": operation list * unit)
else (([]: operation list), unit)
type parameter =
Entrypoint_A of nat
| Entrypoint_B of string
type storage = {
counter : nat;
name : string
}
type return = operation list * storage
let handle_A (n, store : nat * storage) : return =
([] : operation list), {store with counter = n}
let handle_B (s, store : string * storage) : return =
([] : operation list), {store with name = s}
let main (param, store: parameter * storage) : return =
match param with
Entrypoint_A n -> handle_A (n, store)
| Entrypoint_B s -> handle_B (s, store)
```
<!--ReasonLIGO-->
```reasonligo group=b
let main = ((p,s): (unit, unit)) : (list(operation), unit) => {
if (amount > 0mutez) {
(failwith("This contract does not accept tez"): (list(operation), unit));
type parameter =
| Entrypoint_A (nat)
| Entrypoint_B (string);
type storage = {
counter : nat,
name : string
};
type return = (list (operation), storage);
let handle_A = ((n, store): (nat, storage)) : return => {
(([] : list (operation)), {...store, counter : n}); };
let handle_B = ((s, store): (string, storage)) : return => {
(([] : list (operation)), {...store, name : s}); };
let main = ((param, store): (parameter, storage)) : return => {
switch (param) {
| Entrypoint_A (n) => handle_A ((n, store))
| Entrypoint_B (s) => handle_B ((s, store))
}
else {
(([]: list(operation)), ());
};
};
```
<!--END_DOCUSAURUS_CODE_TABS-->
## Tezos-specific Built-ins
A LIGO smart contract can query part of the state of the Tezos
blockchain by means of built-in values. In this section you will find
how those built-ins can be utilized.
### Accepting or Declining Tokens in a Smart Contract
This example shows how `amount` and `failwith` can be used to decline
any transaction that sends more tez than `0mutez`, that is, no
incoming tokens are accepted.
<!--DOCUSAURUS_CODE_TABS-->
<!--PascaLIGO-->
```pascaligo group=c
type parameter is unit
type storage is unit
type return is list (operation) * storage
function deny (const param : parameter; const store : storage) : return is
if amount > 0mutez then
(failwith ("This contract does not accept tokens.") : return)
else ((nil : list (operation)), store)
```
<!--CameLIGO-->
```cameligo group=c
type parameter = unit
type storage = unit
type return = operation list * storage
let deny (param, store : parameter * storage) : return =
if amount > 0mutez then
(failwith "This contract does not accept tokens.": return)
else (([] : operation list), store)
```
<!--ReasonLIGO-->
```reasonligo group=c
type parameter = unit;
type storage = unit;
type return = (list (operation), storage);
let deny = ((param, store): (parameter, storage)) : return => {
if (amount > 0mutez) {
(failwith("This contract does not accept tokens."): return); }
else { (([] : list (operation)), store); };
};
```
@ -178,130 +241,168 @@ let main = ((p,s): (unit, unit)) : (list(operation), unit) => {
This example shows how `sender` or `source` can be used to deny access to an entrypoint.
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
<!--PascaLIGO-->
```pascaligo group=c
const owner: address = ("tz1KqTpEZ7Yob7QbPE4Hy4Wo8fHG8LhKxZSx": address);
function main (const p : unit ; const s : unit) : (list(operation) * unit) is
block {
if source =/= owner then failwith("This address can't call the contract") else skip
} with ((nil : list(operation)), unit);
const owner : address = ("tz1KqTpEZ7Yob7QbPE4Hy4Wo8fHG8LhKxZSx": address);
function filter (const param : parameter; const store : storage) : return is
if source =/= owner then (failwith ("Access denied.") : return)
else ((nil : list(operation)), store)
```
<!--CameLIGO-->
```cameligo group=c
let owner: address = ("tz1KqTpEZ7Yob7QbPE4Hy4Wo8fHG8LhKxZSx": address)
let main (p,s: unit * unit) : operation list * unit =
if source <> owner
then (failwith "This address can't call the contract": operation list * unit)
else (([]: operation list), ())
let owner : address = ("tz1KqTpEZ7Yob7QbPE4Hy4Wo8fHG8LhKxZSx": address)
let filter (param, store: parameter * storage) : return =
if source <> owner then (failwith "Access denied." : return)
else (([] : operation list), store)
```
<!--ReasonLIGO-->
```reasonligo group=c
let owner: address = ("tz1KqTpEZ7Yob7QbPE4Hy4Wo8fHG8LhKxZSx": address);
let main = ((p,s): (unit, unit)) : (list(operation), unit) => {
if (source != owner) {
(failwith("This address can't call the contract"): (list(operation), unit));
}
else {
(([]: list(operation)), ());
};
let owner : address = ("tz1KqTpEZ7Yob7QbPE4Hy4Wo8fHG8LhKxZSx": address);
let main = ((param, store): (parameter, storage)) : storage => {
if (source != owner) { (failwith ("Access denied.") : return); }
else { (([] : list (operation)), store); };
};
```
<!--END_DOCUSAURUS_CODE_TABS-->
### Cross contract calls
### Inter-Contract Invocations
This example shows how a contract can invoke another contract by emiting a transaction operation at the end of an entrypoint.
It would be somewhat misleading to speak of "contract calls", as this
wording may wrongly suggest an analogy between contract "calls" and
function "calls". Indeed, the control flow returns to the site of a
function call, and composed function calls therefore are *stacked*,
that is, they follow a last in, first out ordering. This is not what
happens when a contract invokes another: the invocation is *queued*,
that is, follows a first in, first our ordering, and the dequeuing
only starts at the normal end of a contract (no failure). That is why
we speak of "contract invocations" instead of "calls".
> The same technique can be used to transfer tez to an implicit account (tz1, ...), all you have to do is use `unit` instead of a parameter for a smart contract.
The following example shows how a contract can invoke another by
emiting a transaction operation at the end of an entrypoint.
In our case, we have a `counter.ligo` contract that accepts a parameter of type `action`, and we have a `proxy.ligo` contract that accepts the same parameter type, and forwards the call to the deployed counter contract.
> The same technique can be used to transfer tokens to an implicit
> account (tz1, ...): all you have to do is use a unit value as the
> parameter of the smart contract.
In our case, we have a `counter.ligo` contract that accepts a
parameter of type `action`, and we have a `proxy.ligo` contract that
accepts the same parameter type, and forwards the call to the deployed
counter contract.
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
<!--PascaLIGO-->
```pascaligo skip
// counter.ligo
type action is
| Increment of int
| Decrement of int
| Reset of unit
type parameter is
Increment of nat
| Decrement of nat
| Reset
type storage is unit
type return is list (operation) * storage
```
```pascaligo skip
```pascaligo group=d
// proxy.ligo
type action is
| Increment of int
| Decrement of int
| Reset of unit
type parameter is
Increment of nat
| Decrement of nat
| Reset
const dest: address = ("KT19wgxcuXG9VH4Af5Tpm1vqEKdaMFpznXT3": address);
type storage is unit
function proxy(const param: action; const store: unit): (list(operation) * unit)
is block {
const counter: contract(action) = get_contract(dest);
// re-use the param passed to the proxy in the subsequent transaction
// e.g.:
// const mockParam: action = Increment(5);
const op: operation = transaction(param, 0mutez, counter);
const opList: list(operation) = list op; end;
} with (opList, store)
type return is list (operation) * storage
const dest : address = ("KT19wgxcuXG9VH4Af5Tpm1vqEKdaMFpznXT3" : address)
function proxy (const param : parameter; const store : storage): return is
block {
const counter : contract (parameter) = get_contract (dest);
(* Reuse the parameter in the subsequent
transaction or use another one, `mock_param`. *)
const mock_param : parameter = Increment (5n);
const op : operation = transaction (param, 0mutez, counter);
const ops : list (operation) = list [op]
} with (ops, store)
```
<!--CameLIGO-->
```cameligo
```cameligo skip
// counter.mligo
type action =
| Increment of int
| Decrement of int
| Reset of unit
type paramater =
Increment of nat
| Decrement of nat
| Reset
// ...
```
```cameligo
```cameligo group=d
// proxy.mligo
type action =
| Increment of int
| Decrement of int
| Reset of unit
type parameter =
Increment of nat
| Decrement of nat
| Reset
let dest: address = ("KT19wgxcuXG9VH4Af5Tpm1vqEKdaMFpznXT3": address)
type storage = unit
let proxy (param, storage: action * unit): operation list * unit =
let counter: action contract = Operation.get_contract dest in
let op: operation = Operation.transaction param 0mutez counter in
[op], storage
type return = operation list * storage
let dest : address = ("KT19wgxcuXG9VH4Af5Tpm1vqEKdaMFpznXT3" : address)
let proxy (param, store : parameter * storage) : return =
let counter : parameter contract = Operation.get_contract dest in
(* Reuse the parameter in the subsequent
transaction or use another one, `mock_param`. *)
let mock_param : parameter = Increment (5n) in
let op : operation = Operation.transaction param 0mutez counter
in [op], store
```
<!--ReasonLIGO-->
```reasonligo
```reasonligo skip
// counter.religo
type action =
| Increment(int)
| Decrement(int)
| Reset(unit);
type parameter =
| Increment (nat)
| Decrement (nat)
| Reset
// ...
```
```reasonligo
```reasonligo group=d
// proxy.religo
type action =
| Increment(int)
| Decrement(int)
| Reset(unit);
type parameter =
| Increment (nat)
| Decrement (nat)
| Reset;
let dest: address = ("KT19wgxcuXG9VH4Af5Tpm1vqEKdaMFpznXT3": address);
type storage = unit;
let proxy = ((param, s): (action, unit)): (list(operation), unit) =>
let counter: contract(action) = Operation.get_contract(dest);
let op: operation = Operation.transaction(param, 0mutez, counter);
([op], s);
type return = (list (operation), storage);
let dest : address = ("KT19wgxcuXG9VH4Af5Tpm1vqEKdaMFpznXT3" : address);
let proxy = ((param, store): (parameter, storage)) : return => {
let counter : contract (parameter) = Operation.get_contract (dest);
(* Reuse the parameter in the subsequent
transaction or use another one, `mock_param`. *)
let mock_param : parameter = Increment (5n);
let op : operation = Operation.transaction (param, 0mutez, counter);
([op], store)
};
```
<!--END_DOCUSAURUS_CODE_TABS-->

50
gitlab-pages/docs/advanced/first-contract.md
View File

@ -3,20 +3,24 @@ id: first-contract
title: First contract
---
So far so good, we've learned enough of the LIGO language, we're confident enough to write out first smart contract.
So far so good, we have learned enough of the LIGO language, we are
confident enough to write out first smart contract.
We'll be implementing a counter contract, let's go.
We will be implementing a counter contract.
## Dry-running a contract
## Dry-running a Contract
Testing a contract can be quite easy if we utilize LIGO's built-in dry run feature. Dry-run works by simulating the entrypoint execution, as if it were deployed on a real chain. You need to provide the following:
Testing a contract can be quite easy if we utilize LIGO's built-in dry
run feature. Dry-run works by simulating the access function
execution, as if it were deployed on a real chain. You need to provide
the following:
- `file` - contract to run
- `entrypoint` - name of the function to execute
- `parameter` - parameter passed to the entrypoint (in a theoretical invocation operation)
- `parameter` - parameter passed to the access function (in a theoretical invocation operation)
- `storage` - a mock storage value, as if it were stored on a real chain
Here's a full example:
Here is a full example:
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
@ -29,25 +33,29 @@ ligo dry-run src/basic.ligo main Unit Unit
```
<!--END_DOCUSAURUS_CODE_TABS-->
Output of the `dry-run` is the return value of our entrypoint function, we can see the operations emited - in our case an empty list, and the new storage value being returned - which in our case is still `Unit`.
Output of the `dry-run` is the return value of our access function, we
can see the operations emited - in our case an empty list, and the new
storage value being returned - which in our case is still `Unit`.
## Building a counter contract
## A Counter Contract
Our counter contract will store a single `int` as it's storage, and will accept an `action` variant in order to re-route our single `main` entrypoint into two entrypoints for `addition` and `subtraction`.
Our counter contract will store a single `int` as it's storage, and
will accept an `action` variant in order to re-route our single `main`
access function to two entrypoints for `addition` and `subtraction`.
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
```
type action is
| Increment of int
Increment of int
| Decrement of int
function main (const p : action ; const s : int) : (list(operation) * int) is
block {skip} with ((nil : list(operation)),
case p of
((nil : list(operation)),
(case p of
| Increment (n) -> s + n
| Decrement (n) -> s - n
end)
end))
```
<!--CameLIGO-->
@ -98,11 +106,13 @@ ligo dry-run src/counter.ligo main "Increment(5)" 5
<!--END_DOCUSAURUS_CODE_TABS-->
Yay, our contract's storage has been successfuly incremented to `10`.
Our contract's storage has been successfuly incremented to `10`.
## Deploying and interacting with a contract on a live-chain
In order to deploy the counter contract to a real Tezos network, we'd have to compile it first, this can be done with the help of the `compile-contract` CLI command:
In order to deploy the counter contract to a real Tezos network, we'd
have to compile it first, this can be done with the help of the
`compile-contract` CLI command:
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
@ -156,7 +166,10 @@ Command above will output the following Michelson code:
```
<!--END_DOCUSAURUS_CODE_TABS-->
However in order to originate a Michelson contract on Tezos, we also need to provide the initial storage value, we can use `compile-storage` to compile the LIGO representation of the storage to Michelson.
However in order to originate a Michelson contract on Tezos, we also
need to provide the initial storage value, we can use
`compile-storage` to compile the LIGO representation of the storage to
Michelson.
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
@ -167,7 +180,7 @@ ligo compile-storage src/counter.ligo main 5
<!--END_DOCUSAURUS_CODE_TABS-->
In our case the LIGO storage value maps 1:1 to it's Michelson representation, however this will not be the case once the parameter is of a more complex data type, like a record.
In our case the LIGO storage value maps 1:1 to its Michelson representation, however this will not be the case once the parameter is of a more complex data type, like a record.
## Invoking a LIGO contract
@ -182,4 +195,5 @@ ligo compile-parameter src/counter.ligo main 'Increment(5)'
<!--END_DOCUSAURUS_CODE_TABS-->
Now we can use `(Right 5)` which is a Michelson value, to invoke our contract - e.g. via `tezos-client`
Now we can use `(Right 5)` which is a Michelson value, to invoke our
contract - e.g. via `tezos-client`

4
gitlab-pages/docs/advanced/src/entrypoints-contracts/amount.ligo
View File

@ -1,4 +0,0 @@
function main (const p : unit ; const s : unit) : (list(operation) * unit) is
block {
if amount > 0mutez then failwith("This contract does not accept tez") else skip
} with ((nil : list(operation)), unit);

5
gitlab-pages/docs/advanced/src/entrypoints-contracts/owner.ligo
View File

@ -1,5 +0,0 @@
const owner: address = ("tz1KqTpEZ7Yob7QbPE4Hy4Wo8fHG8LhKxZSx": address);
function main (const p : unit ; const s : unit) : (list(operation) * unit) is
block {
if source =/= owner then failwith("This address can't call the contract") else skip
} with ((nil : list(operation)), unit);

9
gitlab-pages/docs/advanced/src/entrypoints-contracts/transaction/counter.ligo
View File

@ -1,9 +0,0 @@
#include "counter.types.ligo"
function counter (const p : action ; const s : int): (list(operation) * int) is
block { skip } with ((nil : list(operation)),
case p of
| Increment(n) -> s + n
| Decrement(n) -> s - n
| Reset(n) -> 0
end)

4
gitlab-pages/docs/advanced/src/entrypoints-contracts/transaction/counter.types.ligo
View File

@ -1,4 +0,0 @@
type action is
| Increment of int
| Decrement of int
| Reset of unit

14
gitlab-pages/docs/advanced/src/entrypoints-contracts/transaction/proxy.ligo
View File

@ -1,14 +0,0 @@
#include "counter.types.ligo"
// Replace the following address with your deployed counter contract address
const address: address = ("KT19wgxcuXG9VH4Af5Tpm1vqEKdaMFpznXT3": address);
function proxy(const param: action; const store: unit): (list(operation) * unit)
is block {
const counter: contract(action) = get_contract(address);
// re-use the param passed to the proxy in the subsequent transaction
// e.g.:
// const mockParam: action = Increment(5);
const op: operation = transaction(param, 0mutez, counter);
const opList: list(operation) = list op; end;
} with (opList, store)

9
gitlab-pages/docs/advanced/src/timestamps/timestamp.ligo
View File

@ -1,9 +0,0 @@
const today: timestamp = now;
const one_day: int = 86400;
const in_24_hrs: timestamp = today + one_day;
const today: timestamp = now;
const one_day: int = 86400;
const a_24_hrs_ago: timestamp = today - one_day;
const not_tommorow: bool = (now = in_24_hrs)

155
gitlab-pages/docs/advanced/timestamps-addresses.md
View File

@ -3,179 +3,204 @@ id: timestamps-addresses
title: Timestamps, Addresses
---
## Timestamps
## Timestamps
Timestamps in LIGO, or in Michelson in general are available in smart contracts, while bakers baking the block (including the transaction in a block) are responsible for providing the given current timestamp for the contract.
LIGO features timestamps, as Michelson does, while bakers baking the
block (including the transaction in a block) are responsible for
providing the given current timestamp for the contract.
### Current time
You can obtain the current time using the built-in syntax specific expression, please be aware that it's up to the baker to set the current timestamp value.
### Current Time
You can obtain the current time using the built-in syntax specific
expression, please be aware that it is up to the baker to set the
current timestamp value.
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
<!--PascaLIGO-->
```pascaligo group=a
const today: timestamp = now;
const today : timestamp = now
```
<!--CameLIGO-->
```cameligo group=a
let today: timestamp = Current.time
let today : timestamp = Current.time
```
<!--ReasonLIGO-->
```reasonligo group=a
let today: timestamp = Current.time;
let today : timestamp = Current.time;
```
<!--END_DOCUSAURUS_CODE_TABS-->
> When running code with ligo CLI, the option `--predecessor-timestamp` allows you to control what `now` returns.
> When running code with ligo CLI, the option
> `--predecessor-timestamp` allows you to control what `now` returns.
### Timestamp arithmetic
### Timestamp Arithmetic
In LIGO, timestamps can be added with `int`(s), this enables you to set e.g. time constraints for your smart contracts like this:
In LIGO, timestamps can be added to integers, allowing you to set time
constraints on your smart contracts. Consider the following scenarios.
#### In 24 hours
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
<!--PascaLIGO-->
```pascaligo group=b
const today: timestamp = now;
const one_day: int = 86400;
const in_24_hrs: timestamp = today + one_day;
const some_date: timestamp = ("2000-01-01T10:10:10Z" : timestamp);
const one_day_later: timestamp = some_date + one_day;
const today : timestamp = now
const one_day : int = 86400
const in_24_hrs : timestamp = today + one_day
const some_date : timestamp = ("2000-01-01T10:10:10Z" : timestamp)
const one_day_later : timestamp = some_date + one_day
```
<!--CameLIGO-->
```cameligo group=b
let today: timestamp = Current.time
let one_day: int = 86400
let in_24_hrs: timestamp = today + one_day
let some_date: timestamp = ("2000-01-01t10:10:10Z" : timestamp)
let one_day_later: timestamp = some_date + one_day
let today : timestamp = Current.time
let one_day : int = 86400
let in_24_hrs : timestamp = today + one_day
let some_date : timestamp = ("2000-01-01t10:10:10Z" : timestamp)
let one_day_later : timestamp = some_date + one_day
```
<!--ReasonLIGO-->
```reasonligo group=b
let today: timestamp = Current.time;
let one_day: int = 86400;
let in_24_hrs: timestamp = today + one_day;
let some_date: timestamp = ("2000-01-01t10:10:10Z" : timestamp);
let one_day_later: timestamp = some_date + one_day;
let today : timestamp = Current.time;
let one_day : int = 86400;
let in_24_hrs : timestamp = today + one_day;
let some_date : timestamp = ("2000-01-01t10:10:10Z" : timestamp);
let one_day_later : timestamp = some_date + one_day;
```
<!--END_DOCUSAURUS_CODE_TABS-->
#### 24 hours ago
#### 24 hours Ago
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
<!--PascaLIGO-->
```pascaligo group=c
const today: timestamp = now;
const one_day: int = 86400;
const in_24_hrs: timestamp = today - one_day;
const today : timestamp = now
const one_day : int = 86400
const in_24_hrs : timestamp = today - one_day
```
<!--CameLIGO-->
```cameligo group=c
let today: timestamp = Current.time
let one_day: int = 86400
let in_24_hrs: timestamp = today - one_day
let today : timestamp = Current.time
let one_day : int = 86400
let in_24_hrs : timestamp = today - one_day
```
<!--ReasonLIGO-->
```reasonligo group=c
let today: timestamp = Current.time;
let one_day: int = 86400;
let in_24_hrs: timestamp = today - one_day;
let today : timestamp = Current.time;
let one_day : int = 86400;
let in_24_hrs : timestamp = today - one_day;
```
<!--END_DOCUSAURUS_CODE_TABS-->
### Comparing timestamps
### Comparing Timestamps
You can also compare timestamps using the same comparison operators as for numbers:
You can compare timestamps using the same comparison operators
applying to numbers.
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
<!--PascaLIGO-->
```pascaligo group=c
const not_tommorow: bool = (now = in_24_hrs)
const not_tommorow : bool = (now = in_24_hrs)
```
<!--CameLIGO-->
```cameligo group=c
let not_tomorrow: bool = (Current.time = in_24_hrs)
let not_tomorrow : bool = (Current.time = in_24_hrs)
```
<!--ReasonLIGO-->
```reasonligo group=c
let not_tomorrow: bool = (Current.time == in_24_hrs);
let not_tomorrow : bool = (Current.time == in_24_hrs);
```
<!--END_DOCUSAURUS_CODE_TABS-->
## Addresses
`address` is a LIGO datatype used for Tezos addresses (tz1, tz2, tz3, KT1, ...).
Here's how you can define an address:
The type `address` in LIGO denotes Tezos addresses (tz1, tz2, tz3,
KT1, ...). Currently, addresses are created by casting a string to the
type `address`. Beware of failures if the address is invalid. Consider
the following examples.
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
<!--PascaLIGO-->
```pascaligo group=d
const my_account: address = ("tz1KqTpEZ7Yob7QbPE4Hy4Wo8fHG8LhKxZSx": address);
const my_account : address =
("tz1KqTpEZ7Yob7QbPE4Hy4Wo8fHG8LhKxZSx" : address)
```
<!--CameLIGO-->
```cameligo group=d
let my_account: address = ("tz1KqTpEZ7Yob7QbPE4Hy4Wo8fHG8LhKxZSx": address)
let my_account : address =
("tz1KqTpEZ7Yob7QbPE4Hy4Wo8fHG8LhKxZSx" : address)
```
<!--ReasonLIGO-->
```reasonligo group=d
let my_account: address = ("tz1KqTpEZ7Yob7QbPE4Hy4Wo8fHG8LhKxZSx": address);
let my_account : address =
("tz1KqTpEZ7Yob7QbPE4Hy4Wo8fHG8LhKxZSx" : address);
```
<!--END_DOCUSAURUS_CODE_TABS-->
## Signatures
`signature` is a LIGO datatype used for Tezos signature (edsig, spsig).
The `signature` type in LIGO datatype is used for Tezos signatures
(edsig, spsig). Signatures are created by casting a string. Beware of
failure if the signature is invalid.
Here's how you can define a signature:
Here is how you can define a signature:
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
<!--PascaLIGO-->
```pascaligo group=e
const my_signature: signature = ("edsigthTzJ8X7MPmNeEwybRAvdxS1pupqcM5Mk4uCuyZAe7uEk68YpuGDeViW8wSXMrCi5CwoNgqs8V2w8ayB5dMJzrYCHhD8C7": signature);
const my_sig : signature =
("edsigthTzJ8X7MPmNeEwybRAvdxS1pupqcM5Mk4uCuyZAe7uEk68YpuGDeViW8wSXMrCi5CwoNgqs8V2w8ayB5dMJzrYCHhD8C7" :
signature)
```
<!--CameLIGO-->
```cameligo group=e
let my_signature: signature = ("edsigthTzJ8X7MPmNeEwybRAvdxS1pupqcM5Mk4uCuyZAe7uEk68YpuGDeViW8wSXMrCi5CwoNgqs8V2w8ayB5dMJzrYCHhD8C7": signature)
let my_sig : signature =
("edsigthTzJ8X7MPmNeEwybRAvdxS1pupqcM5Mk4uCuyZAe7uEk68YpuGDeViW8wSXMrCi5CwoNgqs8V2w8ayB5dMJzrYCHhD8C7" :
signature)
```
<!--ReasonLIGO-->
```reasonligo group=e
let my_signature: signature = ("edsigthTzJ8X7MPmNeEwybRAvdxS1pupqcM5Mk4uCuyZAe7uEk68YpuGDeViW8wSXMrCi5CwoNgqs8V2w8ayB5dMJzrYCHhD8C7": signature);
let my_sig : signature =
("edsigthTzJ8X7MPmNeEwybRAvdxS1pupqcM5Mk4uCuyZAe7uEk68YpuGDeViW8wSXMrCi5CwoNgqs8V2w8ayB5dMJzrYCHhD8C7" :
signature);
```
<!--END_DOCUSAURUS_CODE_TABS-->
## keys
## Keys
`key` is a LIGO datatype used for Tezos public key.
The `key` type in LIGO is used for Tezos public keys. Do not confuse
them with map keys. Keys are made by casting strings. Beware of
failure if the key is invalid.
Here's how you can define a key:
Here is how you can define a key.
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
<!--PascaLIGO-->
```pascaligo group=f
const my_key: key = ("edpkuBknW28nW72KG6RoHtYW7p12T6GKc7nAbwYX5m8Wd9sDVC9yav": key);
const my_key : key =
("edpkuBknW28nW72KG6RoHtYW7p12T6GKc7nAbwYX5m8Wd9sDVC9yav" : key)
```
<!--CameLIGO-->
```cameligo group=f
let my_key: key = ("edpkuBknW28nW72KG6RoHtYW7p12T6GKc7nAbwYX5m8Wd9sDVC9yav": key)
let my_key : key =
("edpkuBknW28nW72KG6RoHtYW7p12T6GKc7nAbwYX5m8Wd9sDVC9yav" : key)
```
<!--ReasonLIGO-->
```reasonligo group=f
let my_key: key = ("edpkuBknW28nW72KG6RoHtYW7p12T6GKc7nAbwYX5m8Wd9sDVC9yav": key);
let my_key : key =
("edpkuBknW28nW72KG6RoHtYW7p12T6GKc7nAbwYX5m8Wd9sDVC9yav" : key);
```
<!--END_DOCUSAURUS_CODE_TABS-->

4
gitlab-pages/docs/contributors/getting-started.md
View File

@ -23,9 +23,9 @@ The first issues will most likely be:
>Tests are **really** important, we don’t have lots of them, and mostly regression ones. This can’t be stressed enough. Some features are missing not because we can’t add them, but because we don’t know as no tests tell us they are missing.
## How
Issues will be added to Gitlab tagged with `On-boarding and Front-End` / `Middle-End` / `Back-End` / `Everything`.
Issues will be added to GitLab tagged with `On-boarding and Front-End` / `Middle-End` / `Back-End` / `Everything`.
If you try to tackle an issue and you have **any** problem, please tell us by creating a new Gitlab issue, contacting us on Riot, on Discord, or even by mail!
If you try to tackle an issue and you have **any** problem, please tell us by creating a new GitLab issue, contacting us on Riot, on Discord, or even by mail!
Problems might include:
* Installing the repository or the tools needed to work on it

2
gitlab-pages/docs/contributors/ligo_test_guide.md
View File

@ -111,4 +111,4 @@ What if we want to write a test of our own? If the test is in the integration te
1. Write a test contract which uses the new syntax or feature in [src/test/contracts](https://gitlab.com/ligolang/ligo/tree/dev/src/test/contracts).
2. Write an integration test in [src/test/integration_tests.ml](https://gitlab.com/ligolang/ligo/blob/dev/src/test/integration_tests.ml) in the vein of existing tests, make sure you add it to the test runner that is currently located at the bottom of the file.
3. Write the feature, assuming it doesn't already exist. Build the resulting version of LIGO without errors.
4. Run the test suite, see if your test(s) pass. If they do, you're probably done. If not it's time to go debugging.
4. Run the test suite, see if your test(s) pass. If they do, you're probably done. If not, it's time to go debugging.

4
gitlab-pages/docs/contributors/origin.md
View File

@ -3,8 +3,8 @@ id: origin
title: Origin
---
LIGO is a programming language that aims to provide developers with an uncomplicated and safe way to implement smart-contracts. Since it is being implemented for the Tezos blockchain LIGO compiles to Michelson—the native smart-contract language of Tezos.
LIGO is a programming language that aims to provide developers with an uncomplicated and safe way to implement smart contracts. Since it is being implemented for the Tezos blockchain LIGO compiles to Michelson—the native smart contract language of Tezos.
> Smart-contracts are programs that run within a blockchain network.
> Smart contracts are programs that run within a blockchain network.
LIGO was meant to be a language for developing Marigold on top of a hacky framework called Meta-Michelson. However, due to the attention received by the Tezos community, LIGO is now a standalone language being developed to support Tezos directly.

4
gitlab-pages/docs/contributors/philosophy.md
View File

@ -6,7 +6,7 @@ title: Philosophy
To understand LIGO’s design choices it’s important to understand its philosophy. We have two main concerns in mind while building LIGO.
## Safety
Once a smart-contract is deployed, it will likely be impossible to change it. You must get it right on the first try, and LIGO should help as much as possible. There are multiple ways to make LIGO a safer language for smart-contracts.
Once a smart contract is deployed, it will likely be impossible to change it. You must get it right on the first try, and LIGO should help as much as possible. There are multiple ways to make LIGO a safer language for smart contracts.
### Automated Testing
Automated Testing is the process through which a program runs another program, and checks that this other program behaves correctly.
@ -18,7 +18,7 @@ Static analysis is the process of having a program analyze another one.
For instance, type systems are a kind of static analysis through which it is possible to find lots of bugs. LIGO already has a simple type system, and we plan to make it much stronger.
### Conciseness
Writing less code gives you less room to introduce errors. That's why LIGO encourages writing lean rather than chunky smart-contracts.
Writing less code gives you less room to introduce errors. That's why LIGO encourages writing lean rather than chunky smart contracts.
---

4
gitlab-pages/docs/intro/installation.md
View File

@ -15,12 +15,12 @@ executable (see below). This manages the Docker bits for you.
* Use the Docker image available at [Docker Hub](https://hub.docker.com/r/ligolang/ligo).
This lets you run multiple versions and keep your installation(s) self contained, but requires more familiarity with Docker.
Sources for the image can be found on [Gitlab](https://gitlab.com/ligolang/ligo/blob/master/docker/Dockerfile).
Sources for the image can be found on [GitLab](https://gitlab.com/ligolang/ligo/blob/master/docker/Dockerfile).
If this is your first time using Docker, you probably want to set up a global LIGO executable as shown below.
### Setting up a globally available `ligo` executable
> You can install additional ligo versions by replacing `next` with the required version number
> You can install additional ligo versions by replacing `next` with the desired version number
Download the latest binaries here: https://gitlab.com/ligolang/ligo/pipelines/85536879/builds or get the latest pre-release:

35
gitlab-pages/docs/intro/src/what-and-why/ligo-counter.ligo
View File

@ -1,12 +1,25 @@
type action is
| Increment of int
| Decrement of int
| Reset of unit
type storage is int
function main (const p : action ; const s : int) : (list(operation) * int) is
block { skip } with ((nil : list(operation)),
case p of
| Increment(n) -> s + n
| Decrement(n) -> s - n
| Reset(n) -> 0
end)
type parameter is
Increment of int
| Decrement of int
| Reset
type return is list (operation) * storage
(* Two entrypoints *)
function add (const store : storage; const delta : int) : storage is store + delta
function sub (const store : storage; const delta : int) : storage is store - delta
(* Main access point that dispatches to the entrypoints according to
the smart contract parameter. *)
function main (const action : parameter; const store : storage) : return is
((nil : list (operation)), // No operations
case action of
Increment (n) -> add (store, n)
| Decrement (n) -> sub (store, n)
| Reset -> 0
end)

23
gitlab-pages/docs/intro/src/what-and-why/ligo-counter.mligo Normal file
View File

@ -0,0 +1,23 @@
type storage = int
type parameter =
Increment of int
| Decrement of int
| Reset
type return = operation list * storage
(* Two entrypoints *)
let add (store, delta : storage * int) : storage = store + delta
let sub (store, delta : storage * int) : storage = store - delta
(* Main access point that dispatches to the entrypoints according to
the smart contract parameter. *)
let main (action, store : parameter * storage) : return =
([] : operation list), // No operations
(match action with
Increment (n) -> add (store, n)
| Decrement (n) -> sub (store, n)
| Reset -> 0)

26
gitlab-pages/docs/intro/src/what-and-why/ligo-counter.religo Normal file
View File

@ -0,0 +1,26 @@
type storage = int;
type parameter =
Increment (int)
| Decrement (int)
| Reset;
type return = (list (operation), storage);
(* Two entrypoints *)
let add = ((store, delta) : (storage, int)) : storage => store + delta;
let sub = ((store, delta) : (storage, int)) : storage => store - delta;
(* Main access point that dispatches to the entrypoints according to
the smart contract parameter. *)
let main = ((action, store) : (parameter, storage)) : return => {
(([] : list (operation)), // No operations
(switch (action) {
| Increment (n) => add ((store, n))
| Decrement (n) => sub ((store, n))
| Reset => 0
}))
};

254
gitlab-pages/docs/intro/what-and-why.md
View File

@ -1,14 +1,73 @@
---
id: what-and-why
title: What & Why
title: Michelson and LIGO
---
Before we get into what LIGO is and why LIGO needs to exist, let's take a look at what options the Tezos blockchain offers us out of the box. If you want to implement smart contracts natively on Tezos, you have to learn [Michelson](https://tezos.gitlab.io/whitedoc/michelson.html).
Before we get into what LIGO is and why LIGO needs to exist, let us
take a look at what options the Tezos blockchain offers us out of the
box. If you want to implement smart contracts natively on Tezos, you
have to learn
[Michelson](https://tezos.gitlab.io/whitedoc/michelson.html).
> 💡 The (Michelson) language is stack-based, with high level data types and primitives and strict static type checking.
**The rationale and design of Michelson**
The language native to the Tezos blockchain for writing smart
contracts is *Michelson*, a Domain-Specific Language (DSL) inspired by
Lisp and Forth. This unusual lineage aims at satisfying unusual
constraints, but entails some tensions in the design.
Here's an example of Michelson code:
First, to measure stepwise gas consumption, *Michelson is interpreted*.
On the one hand, to assess gas usage per instruction, instructions
should be simple, which points to low-level features (a RISC-like
language). On the other hand, it was originally thought that users
will want to write in Michelson instead of lowering a language to
Michelson, because the gas cost would otherwise be harder to
predict. This means that *high-level features* were deemed necessary
(like a restricted variant of Lisp lambdas, a way to encode algebraic
data types, as well as built-in sets, maps and lists).
To avoid ambiguous and otherwise misleading contracts, the layout of
Michelson contracts has been constrained (e.g., indentation, no
UTF-8), and a *canonical form* was designed and enforced when storing
contracts on the chain.
To reduce the size of the code, Michelson was designed as *a
stack-based language*, whence the lineage from Forth and other
concatenative languages like PostScript, Joy, Cat, Factor etc. (Java
bytecode would count too.)
Programs in those languages are *compact* because they assume an
implicit stack in which some input values are popped, and output
values are pushed, according to the current instruction being
executed.
*Each Michelson instruction modifies a prefix of the stack*, that is,
a segment starting at the top.
Whilst the types of Michelson instructions can be polymorphic, their
instantiations must be monomorphic, hence *Michelson instructions are
not first-class values* and cannot be partially interpreted.
This enables a simple *static type checking*, as opposed to a complex
type inference. It can be performed efficiently: *contract type
checking consumes gas*. Basically, type checking aims at validating
the composition of instructions, therefore is key to safely composing
contracts (concatenation, activations). Once a contract passes type
checking, it cannot fail due to inconsistent assumptions on the
storage and other values (there are no null values, no casts), but it
can still fail for other reasons: division by zero, token exhaustion,
gas exhaustion, or an explicit `FAILWITH` instruction. This property
is called *type safety*. Also, such a contract cannot remain stuck:
this is the *progress property*.
The existence of a formal type system for Michelson, of a formal
specification of its dynamic semantics (evaluation), of a Michelson
interpreter in Coq, of proofs in Coq of properties of some typical
contracts, all those achievements are instances of *formal methods in
Tezos*.
Here is an example of a Michelson contract.
**`counter.tz`**
```text
@ -21,118 +80,167 @@ Here's an example of Michelson code:
NIL operation ; PAIR } }
```
The contract above maintains an `int` in its storage. It has two entrypoints *(functions)* `add` and `sub` to modify it, and the default *entrypoint* of type unit will reset it to 0.
The contract above maintains an `int` as its storage. It has two
[entrypoints](https://tezos.gitlab.io/whitedoc/michelson.html#entrypoints),
`add` and `sub`, to modify it, and the `default` entrypoint of type
`unit` will reset it to `0`.
The contract itself contains three main parts:
The contract itself contains three sections:
- `parameter` - The argument provided by a transaction invoking the contract.
- `storage` - The type definition for the contract's data storage.
- `code` - Actual Michelson code that has the provided parameter and
the current storage value in its initial stack. It outputs in the
resulting stack a pair made of a list of operations and a new
storage value.
- `parameter` - Argument provided by a transaction invoking the contract
- `storage` - Type definition for the contract's data storage.
- `code` - Actual Michelson code that has the provided parameter & the current storage value in its initial stack. It outputs a pair of operations and a new storage value as its resulting stack.
Michelson code consists of *instructions* like `IF_LEFT`, `PUSH ...`,
`UNPAIR` etc. that are composed sequentially in what is called a
*sequence*. The implicit stack contains at all times the state of the
evaluation of the program, whilst the storage represents the
persistent state. If the contract execution is successful, the new
storage state will be committed to the chain and become visible to all
the nodes. Instructions are used to transform a prefix of the stack,
that is, the topmost part of it, for example, by duplicating its top
element, dropping it, subtracting the first two etc.
Michelson code consists of *instructions* like `IF_LEFT`, `PUSH ...`, `UNPAIR` that are bundled togeter in what is called a *sequence*. Stack represents an intermediate state of the program, while **storage represents a persistent state**. Instructions are used to modify the run-time stack in order to yield a desired stack value when the program terminates.
> 💡 A Michelson program running on the Tezos blockchain is meant to
> output a pair of values including a `list of operations` to include
> in a transaction, and a new `storage` value to persist on the chain.
> 💡 A Michelson program running on the Tezos blockchain is meant to output a pair of values including a `list of operations` to emit and a new `storage` value to persist
## Stack versus variables
## Differences between a stack and traditional variable management
Stack management might be a little bit challanging, especially if you're coming from a *C-like language*. Let's implement a similar program in Javascript:
Perhaps the biggest challenge when programming in Michelson is the
lack of *variables* to denote the data: the stack layout has to be
kept in mind when retrieving and storing data. For example, let us
implement a program in Javascript that is similar to the Michelson
above:
**`counter.js`**
```javascript
var storage = 0;
function add(a) {
storage += a
}
function add (a) { storage += a; }
function sub (a) { storage -= a; }
function sub(a) {
storage -= a
}
// We are calling this function "reset" instead of "default"
// because `default` is a Javascript keyword
// We're calling this function reset instead of default
// because `default` is a javascript keyword
function reset() {
storage = 0;
}
function reset () { storage = 0; }
```
In our javascript program the initial `storage` value is `0` and it can be modified by running the functions `add(a)`, `sub(a)` and `reset()`.
In our Javascript program the initial `storage` value is `0` and it
can be modified by calling `add (a)`, `sub (a)` and `reset ()`.
Unfortunately (???), we **can't run Javascript on the Tezos blockchain** at the moment. But we can choose LIGO, which will abstract the stack management and allow us to create readable, type-safe, and efficient smart contracts.
We cannot run Javascript on the Tezos blockchain, but we can choose
LIGO, which will abstract the stack management and allow us to create
readable, type-safe, and efficient smart contracts.
> 💡 You can try running the javascript program [here](https://codepen.io/maht0rz/pen/dyyvoPQ?editors=0012)
## LIGO for Programming Smart Contracts on Tezos
## C-like smart contracts instead of Michelson
Perhaps the most striking feature of LIGO is that it comes in
different concrete syntaxes, and even different programming
paradigms. In other words, LIGO is not defined by one syntax and one
paradigm, like imperative versus functional.
Let's take a look at a similar LIGO program. Don't worry if it's a little confusing at first; we'll explain all the syntax in the upcoming sections of the documentation.
- There is **PascaLIGO**, which is inspired by Pascal, hence is an
imperative language with lots of keywords, where values can be
locally mutated after they have been annotated with their types
(declaration).
- There is **CameLIGO**, which is inspired by the pure subset of
[OCaml](https://ocaml.org/), hence is a functional language with
few keywords, where values cannot be mutated, but still require
type annotations (unlike OCaml, whose compiler performs almost
full type inference).
- There is **ReasonLIGO**, which is inspired by the pure subset of
[ReasonML](https://reasonml.github.io/), which is based upon
OCaml.
Let us decline the same LIGO contract in the three flavours above. Do
not worry if it is a little confusing at first; we will explain all
the syntax in the upcoming sections of the documentation.
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
```pascaligo
type action is
| Increment of int
| Decrement of int
| Reset of unit
```pascaligo group=a
type storage is int
function main (const p : action ; const s : int) : (list(operation) * int) is
block { skip } with ((nil : list(operation)),
case p of
| Increment(n) -> s + n
| Decrement(n) -> s - n
| Reset(n) -> 0
type parameter is
Increment of int
| Decrement of int
| Reset
type return is list (operation) * storage
function main (const action : parameter; const store : storage) : return is
((nil : list (operation)),
case action of
Increment (n) -> store + n
| Decrement (n) -> store - n
| Reset -> 0
end)
```
<!--CameLIGO-->
```cameligo
type action =
| Increment of int
| Decrement of int
| Reset of unit
```cameligo group=a
type storage = int
let main (p, s: action * int) : operation list * int =
let result =
match p with
| Increment n -> s + n
| Decrement n -> s - n
| Reset n -> 0
in
(([]: operation list), result)
type parameter =
Increment of int
| Decrement of int
| Reset
type return = operation list * storage
let main (action, store : parameter * storage) : return =
([] : operation list),
(match action with
Increment n -> store + n
| Decrement n -> store - n
| Reset -> 0)
```
<!--ReasonLIGO-->
```reasonligo
type action =
| Increment(int)
| Decrement(int)
| Reset(unit);
```reasonligo group=a
type storage = int;
let main = ((p,s): (action, int)) : (list(operation), int) => {
let result =
switch (p) {
| Increment(n) => s + n
| Decrement(n) => s - n
| Reset n => 0
};
(([]: list(operation)), result);
type parameter =
Increment (int)
| Decrement (int)
| Reset;
type return = (list (operation), storage);
let main = ((action, store): (parameter, storage)) : return => {
(([] : list (operation)),
(switch (action) {
| Increment (n) => store + n
| Decrement (n) => store - n
| Reset => 0}));
};
```
<!--END_DOCUSAURUS_CODE_TABS-->
<!--
> 💡 You can find the Michelson compilation output of the contract -->
<!--above in **`ligo-counter.tz`** -->
> 💡 You can find the Michelson compilation output of the contract above in **`ligo-counter.tz`**
This LIGO contract behaves almost exactly* like the Michelson
contract we saw first, and it accepts the following LIGO expressions:
`Increment(n)`, `Decrement(n)` and `Reset`. Those serve as
`entrypoint` identification, same as `%add` `%sub` or `%default` in
the Michelson contract.
The LIGO contract behaves exactly* like the Michelson contract we've saw first, and it accepts the following LIGO expressions/values: `Increment(n)`, `Decrement(n)` and `Reset(n)`. Those serve as `entrypoint` identification, same as `%add` `%sub` or `%default` in the Michelson contract.
**not exactly, the Michelson contract also checks if the `AMOUNT` sent is `0`*
**The Michelson contract also checks if the `AMOUNT` sent is `0`*
---
## Runnable code snippets & exercises
Some of the sections in this documentation will include runnable code snippets and exercises. Sources for those are available at
the [LIGO Gitlab repository](https://gitlab.com/ligolang/ligo).
the [LIGO Gitlab repository](https://gitlab.com/ligolang/ligo).
### Snippets
For example **code snippets** for the *Types* subsection of this doc, can be found here:
@ -141,7 +249,7 @@ For example **code snippets** for the *Types* subsection of this doc, can be fou
### Exercises
Solutions to exercises can be found e.g. here: `gitlab-pages/docs/language-basics/exercises/types/**/solutions/**`
### Running snippets / excercise solutions
### Running snippets / exercise solutions
In certain cases it makes sense to be able to run/evaluate the given snippet or a solution, usually there'll be an example command which you can use, such as:
```shell

220
gitlab-pages/docs/language-basics/boolean-if-else.md
View File

@ -1,192 +1,182 @@
---
id: boolean-if-else
title: Boolean, If, Else
title: Booleans and Conditionals
---
## Boolean
## Booleans
The type of a Boolean is `bool` and the possible values are `True` and `False`.
Here's how to define a boolean:
The type of a boolean value is `bool`. Here is how to define a boolean
value:
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
<!--PascaLIGO-->
```pascaligo group=a
const a: bool = True;
const b: bool = False;
const a : bool = True // Notice the capital letter
const b : bool = False // Same.
```
<!--CameLIGO-->
```cameligo group=a
let a: bool = true
let b: bool = false
let a : bool = true
let b : bool = false
```
<!--ReasonLIGO-->
```reasonligo group=a
let a: bool = true;
let b: bool = false;
let a : bool = true;
let b : bool = false;
```
<!--END_DOCUSAURUS_CODE_TABS-->
## Comparing Values
## Comparing two values
In LIGO, only values of the same type can be compared. Moreover, not
all values of the same type can be compared, only those with
*comparable types*, which is a concept lifted from
Michelson. Comparable types include, for instance, `int`, `nat`,
`string`, `tez`, `timestamp`, `address`, etc. As an example of
non-comparable types: maps, sets or lists are not comparable: if you
wish to compare them, you will have to write your own comparison
function.
In LIGO, only values of the same type can be compared. We call these "comparable types." Comparable types include e.g. `int`, `nat`, `string`, `tez`, `timestamp`, `address`, ...
### Comparing strings
### Comparing Strings
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
<!--PascaLIGO-->
```pascaligo group=b
const a: string = "Alice";
const b: string = "Alice";
// True
const c: bool = (a = b);
const a : string = "Alice"
const b : string = "Alice"
const c : bool = (a = b) // True
```
<!--CameLIGO-->
```cameligo group=b
let a: string = "Alice"
let b: string = "Alice"
// true
let c: bool = (a = b)
let a : string = "Alice"
let b : string = "Alice"
let c : bool = (a = b) // true
```
<!--ReasonLIGO-->
```reasonligo group=b
let a: string = "Alice";
let b: string = "Alice";
(* true *)
let c: bool = (a == b);
let a : string = "Alice";
let b : string = "Alice";
let c : bool = (a == b); // true
```
<!--END_DOCUSAURUS_CODE_TABS-->
### Comparing numbers
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
<!--PascaLIGO-->
```pascaligo group=c
const a: int = 5;
const b: int = 4;
const c: bool = (a = b);
const d: bool = (a > b);
const e: bool = (a < b);
const f: bool = (a <= b);
const g: bool = (a >= b);
const h: bool = (a =/= b);
const a : int = 5
const b : int = 4
const c : bool = (a = b)
const d : bool = (a > b)
const e : bool = (a < b)
const f : bool = (a <= b)
const g : bool = (a >= b)
const h : bool = (a =/= b)
```
<!--CameLIGO-->
```cameligo group=c
let a: int = 5
let b: int = 4
let c: bool = (a = b)
let d: bool = (a > b)
let e: bool = (a < b)
let f: bool = (a <= b)
let g: bool = (a >= b)
let h: bool = (a <> b)
let a : int = 5
let b : int = 4
let c : bool = (a = b)
let d : bool = (a > b)
let e : bool = (a < b)
let f : bool = (a <= b)
let g : bool = (a >= b)
let h : bool = (a <> b)
```
<!--ReasonLIGO-->
```reasonligo group=c
let a: int = 5;
let b: int = 4;
let c: bool = (a == b);
let d: bool = (a > b);
let e: bool = (a < b);
let f: bool = (a <= b);
let g: bool = (a >= b);
let h: bool = (a != b);
let a : int = 5;
let b : int = 4;
let c : bool = (a == b);
let d : bool = (a > b);
let e : bool = (a < b);
let f : bool = (a <= b);
let g : bool = (a >= b);
let h : bool = (a != b);
```
<!--END_DOCUSAURUS_CODE_TABS-->
### Comparing tez
> 💡 Comparing `tez` values is especially useful when dealing with an `amount` sent in a transaction.
> 💡 Comparing `tez` values is especially useful when dealing with an
> amount sent in a transaction.
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
<!--PascaLIGO-->
```pascaligo group=d
const a: tez = 5mutez;
const b: tez = 10mutez;
const c: bool = (a = b);
const a : tez = 5mutez
const b : tez = 10mutez
const c : bool = (a = b) // False
```
<!--CameLIGO-->
```cameligo group=d
let a: tez = 5mutez
let b: tez = 10mutez
// false
let c: bool = (a = b)
let a : tez = 5mutez
let b : tez = 10mutez
let c : bool = (a = b) // false
```
<!--ReasonLIGO-->
```reasonligo group=d
let a: tez = 5mutez;
let b: tez = 10mutez;
(* false *)
let c: bool = (a == b);
let a : tez = 5mutez;
let b : tez = 10mutez;
let c : bool = (a == b); // false
```
<!--END_DOCUSAURUS_CODE_TABS-->
## Conditionals, if staments, and more
## Conditionals
Conditional logic is an important part of every real world program.
### If/else statements
Conditional logic enables forking the control flow depending on the
state.
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
<!--PascaLIGO-->
```pascaligo group=e
const min_age: nat = 16n;
type magnitude is Small | Large // See variant types.
function is_adult(const age: nat): bool is
if (age > min_age) then True else False
function compare (const n : nat) : magnitude is
if n < 10n then Small (Unit) else Large (Unit) // Unit is needed for now.
```
> You can run the function above with
> ```
> ligo run-function -s pascaligo src/if-else.ligo is_adult 21n
> ```
You can run the `compare` function defined above using the LIGO compiler
like this:
```shell
ligo run-function
gitlab-pages/docs/language-basics/boolean-if-else/cond.ligo compare 21n'
# Outputs: Large (Unit)
```
<!--CameLIGO-->
```cameligo group=e
let min_age: nat = 16n
type magnitude = Small | Large // See variant types.
(**
This function is really obnoxious, but it showcases
how the if statement and it's syntax can be used.
Normally, you'd use `with (age > min_age)` instead.
*)
let is_adult (age: nat) : bool =
if (age > min_age) then true else false
let compare (n : nat) : magnitude =
if n < 10n then Small else Large
```
You can run the `compare` function defined above using the LIGO compiler
like this:
```shell
ligo run-function
gitlab-pages/docs/language-basics/boolean-if-else/cond.mligo compare 21n'
# Outputs: Large
```
<!--ReasonLIGO-->
```reasonligo group=e
let min_age: nat = 16n;
type magnitude = | Small | Large; // See variant types.
(**
This function is really obnoxious, but it showcases
how the if statement and it's syntax can be used.
Normally, you'd use `with (age > min_age)` instead.
*)
let is_adult = (age: nat): bool =>
if (age > min_age) {
true;
} else {
false;
};
let compare = (n : nat) : magnitude =>
if (n < 10n) { Small; } else { Large; };
```
> You can run the function above with
> ```
> ligo run-function -s reasonligo src/if-else.religo is_adult 21n
> ```
<!--END_DOCUSAURUS_CODE_TABS-->
You can run the `compare` function defined above using the LIGO compiler
like this:
```shell
ligo run-function
gitlab-pages/docs/language-basics/boolean-if-else/cond.religo compare 21n'
# Outputs: Large
```
<!--END_DOCUSAURUS_CODE_TABS-->

245
gitlab-pages/docs/language-basics/functions.md
View File

@ -3,83 +3,119 @@ id: functions
title: Functions
---
Writing code is fun as long as it doesn't get out of hand. To make sure our code doesn't turn into spaghetti we can group some logic into functions.
LIGO features functions are the basic building block of contracts. For
example, entrypoints are functions.
## Instruction blocks
With `block`(s) you can wrap *instructions* and *expressions* into an isolated scope.
Each `block` needs to include at least one `instruction`, or a *placeholder* instruction called `skip`.
## Declaring Functions
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
<!--PascaLIGO-->
There are two ways in PascaLIGO to define functions: with or without a
*block*.
### Blocks
In PascaLIGO, *blocks* enable the sequential composition of
instructions into an isolated scope. Each block needs to include at
least one instruction.
```pascaligo skip
// shorthand syntax
block { a := a + 1 }
// verbose syntax
begin
a := a + 1
end
```
<!--END_DOCUSAURUS_CODE_TABS-->
If we need a placeholder, we use the instruction `skip` which leaves
the state unchanged. The rationale for `skip` instead of a truly
empty block is that it prevents you from writing an empty block by
mistake.
## Defining a function
```pascaligo skip
block { skip }
```
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
Blocks are more versatile than simply containing instructions: they
can also include *declarations* of values, like so:
```pascaligo skip
block { const a : int = 1 }
```
Functions in PascaLIGO are defined using the `function` keyword
followed by their `name`, `parameters` and `return` type definitions.
Here's how you define a basic function that accepts two `int`s and
returns a single `int`:
Here is how you define a basic function that computes the sum of two
integers:
```pascaligo group=a
function add(const a: int; const b: int): int is
begin
const result: int = a + b;
end with result;
function add (const a : int; const b : int) : int is
block {
const sum : int = a + b
} with sum
```
The function body consists of two parts:
- `block {<code>}` - logic of the function
- `with <value>` - the return value of the function
- `block { <instructions and declarations> }` is the logic of the function;
- `with <value>` is the value returned by the function.
#### Blockless functions
### Blockless functions
Functions that can contain all of their logic into a single
instruction/expression, can be defined without the surrounding
`block`. Instead, you can inline the necessary logic directly, like
this:
*expression* can be defined without the need of a block:
```pascaligo
function identity (const n : int) : int is block { skip } with n // Bad! Empty block not needed!
function identity (const n : int) : int is n // Blockless
```
The value of the expression is implicitly returned by the
function. Another example is as follows:
```pascaligo group=b
function add(const a: int; const b: int): int is a + b
function add (const a: int; const b : int) : int is a + b
```
You can call the function `add` defined above using the LIGO compiler
like this:
```shell
ligo run-function gitlab-pages/docs/language-basics/src/functions/blockless.ligo add '(1,2)'
# Outputs: 3
```
<!--CameLIGO-->
Functions in CameLIGO are defined using the `let` keyword, like value
bindings. The difference is that after the value name a list of
function parameters is provided, along with a return type.
Functions in CameLIGO are defined using the `let` keyword, like other
values. The difference is that a succession of parameters is provided
after the value name, followed by the return type. This follows OCaml
syntax. For example:
```cameligo group=c
let add (a : int) (b : int) : int = a + b
```
You can call the function `add` defined above using the LIGO compiler
like this:
```shell
ligo run-function gitlab-pages/docs/language-basics/src/functions/blockless.mligo add '(1,2)'
# Outputs: 3
```
CameLIGO is a little different from other syntaxes when it comes to
function parameters. In OCaml, functions can only take one
parameter. To get functions with multiple arguments like we are used
to in traditional programming languages, a technique called
to in imperative programming languages, a technique called
[currying](https://en.wikipedia.org/wiki/Currying) is used. Currying
essentially translates a function with multiple arguments into a
series of single argument functions, each returning a new function
accepting the next argument until every parameter is filled. This is
useful because it means that CameLIGO can support
useful because it means that CameLIGO supports
[partial application](https://en.wikipedia.org/wiki/Partial_application).
Currying is however *not* the preferred way to pass function arguments
in CameLIGO. While this approach is faithful to the original OCaml,
it's costlier in Michelson than naive function execution accepting
multiple arguments. Instead for most functions with more than one
parameter we should place the arguments in a
it is costlier in Michelson than naive function execution accepting
multiple arguments. Instead, for most functions with more than one
parameter, we should gather the arguments in a
[tuple](language-basics/sets-lists-tuples.md) and pass the tuple in as
a single parameter.
@ -87,56 +123,139 @@ Here is how you define a basic function that accepts two `ints` and
returns an `int` as well:
```cameligo group=b
let add (a,b: int * int) : int = a + b
let add_curry (a: int) (b: int) : int = a + b
let add (a, b : int * int) : int = a + b // Uncurried
let add_curry (a : int) (b : int) : int = add (a, b) // Curried
let increment (b : int) : int = add_curry 1 // Partial application
```
The function body is a series of expressions, which are evaluated to
give the return value.
You can run the `increment` function defined above using the LIGO
compiler like this:
```shell
ligo run-function gitlab-pages/docs/language-basics/src/functions/curry.mligo increment 5
# Outputs: 6
```
<!--ReasonLIGO-->
The function body is a single expression, whose value is returned.
Functions in ReasonLIGO are defined using the `let` keyword, like
value bindings. The difference is that after the value name a list of
function parameters is provided, along with a return type.
Here is how you define a basic function that accepts two `int`s and
returns an `int` as well:
<!--ReasonLIGO--> Functions in ReasonLIGO are defined using the `let`
keyword, like other values. The difference is that a tuple of
parameters is provided after the value name, with its type, then
followed by the return type.
Here is how you define a basic function that sums two integers:
```reasonligo group=b
let add = ((a,b): (int, int)) : int => a + b;
let add = ((a, b): (int, int)) : int => a + b;
```
The function body is a series of expressions, which are evaluated to
give the return value.
You can call the function `add` defined above using the LIGO compiler
like this:
```shell
ligo run-function gitlab-pages/docs/language-basics/src/functions/blockless.religo add '(1,2)'
# Outputs: 3
```
The function body is a single expression, whose value is returned.
<!--END_DOCUSAURUS_CODE_TABS-->
## Anonymous functions
## Anonymous functions (a.k.a. lambdas)
Functions without a name, also known as anonymous functions are useful
in cases when you want to pass the function as an argument or assign
it to a key in a record or a map.
It is possible to define functions without assigning them a name. They
are useful when you want to pass them as arguments, or assign them to
a key in a record or a map.
Here is how to define an anonymous function:
Here's how to define an anonymous function assigned to a variable
`increment`, with it is appropriate function type signature.
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
<!--PascaLIGO-->
```pascaligo group=c
const increment : int -> int = function (const i : int) : int is i + 1;
// a = 2
const a: int = increment (1);
function increment (const b : int) : int is
(function (const a : int) : int is a + 1) (b)
const a : int = increment (1); // a = 2
```
You can check the value of `a` defined above using the LIGO compiler
like this:
```shell
ligo evaluate-value gitlab-pages/docs/language-basics/src/functions/anon.ligo a
# Outputs: 2
```
<!--CameLIGO-->
```cameligo group=c
let increment : int -> int = fun (i: int) -> i + 1
let increment (b : int) : int = (fun (a : int) -> a + 1) b
let a : int = increment 1 // a = 2
```
You can check the value of `a` defined above using the LIGO compiler
like this:
```shell
ligo evaluate-value gitlab-pages/docs/language-basics/src/functions/anon.mligo a
# Outputs: 2
```
<!--ReasonLIGO-->
```reasonligo group=c
let increment: (int => int) = (i: int) => i + 1;
let increment = (b : int) : int => ((a : int) : int => a + 1)(b);
let a : int = increment (1); // a == 2
```
You can check the value of `a` defined above using the LIGO compiler
like this:
```shell
ligo evaluate-value gitlab-pages/docs/language-basics/src/functions/anon.religo a
# Outputs: 2
```
<!--END_DOCUSAURUS_CODE_TABS-->
If the example above seems contrived, here is a more common design
pattern for lambdas: to be used as parameters to functions. Consider
the use case of having a list of integers and mapping the increment
function to all its elements.
<!--DOCUSAURUS_CODE_TABS-->
<!--PascaLIGO-->
```pascaligo group=c
function incr_map (const l : list (int)) : list (int) is
list_map (function (const i : int) : int is i + 1, l)
```
You can call the function `incr_map` defined above using the LIGO compiler
like so:
```shell
ligo run-function
gitlab-pages/docs/language-basics/src/functions/incr_map.ligo incr_map
"list [1;2;3]"
# Outputs: [ 2 ; 3 ; 4 ]
```
<!--CameLIGO-->
```cameligo group=c
let incr_map (l : int list) : int list =
List.map (fun (i : int) -> i + 1) l
```
You can call the function `incr_map` defined above using the LIGO compiler
like so:
```shell
ligo run-function
gitlab-pages/docs/language-basics/src/functions/incr_map.mligo incr_map
"list [1;2;3]"
# Outputs: [ 2 ; 3 ; 4 ]
```
<!--ReasonLIGO-->
```reasonligo group=c
let incr_map = (l : list (int)) : list (int) =>
List.map ((i : int) => i + 1, l);
```
You can call the function `incr_map` defined above using the LIGO compiler
like so:
```shell
ligo run-function
gitlab-pages/docs/language-basics/src/functions/incr_map.religo incr_map
"list [1;2;3]"
# Outputs: [ 2 ; 3 ; 4 ]
```
<!--END_DOCUSAURUS_CODE_TABS-->

269
gitlab-pages/docs/language-basics/loops.md
View File

@ -3,108 +3,233 @@ id: loops
title: Loops
---
## While Loop
## General Iteration
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
<!--PascaLIGO-->
The PascaLIGO while loop should look familiar to users of imperative languages.
While loops are of the form `while <condition clause> <block>`, and evaluate
their associated block until the condition evaluates to false.
General iteration in PascaLIGO takes the shape of general loops, which
should be familiar to programmers of imperative languages as "while
loops". Those loops are of the form `while <condition> <block>`. Their
associated block is repeatedly evaluated until the condition becomes
true, or never evaluated if the condition is false at the start. The
loop never terminates if the condition never becomes true. Because we
are writing smart contracts on Tezos, when the condition of a "while"
loops fails to become true, the execution will run out of gas and stop
with a failure anyway.
> ⚠️ The current PascaLIGO while loop has semantics that have diverged from other LIGO syntaxes. The goal of LIGO is that the various syntaxes express the same semantics, so this will be corrected in future versions. For details on how loops will likely work after refactoring, see the CameLIGO tab of this example.
Here is how to compute the greatest common divisors of two natural
number by means of Euclid's algorithm:
```pascaligo
function while_sum (var n : nat) : nat is block {
var i : nat := 0n ;
var r : nat := 0n ;
while i < n block {
i := i + 1n;
r := r + i;
}
} with r
```pascaligo group=a
function gcd (var x : nat; var y : nat) : nat is
block {
if x < y then
block {
const z : nat = x;
x := y; y := z
}
else skip;
var r : nat := 0n;
while y =/= 0n block {
r := x mod y;
x := y;
y := r
}
} with x
```
You can call the function `gcd` defined above using the LIGO compiler
like so:
```shell
ligo run-function
gitlab-pages/docs/language-basics/src/loops/gcd.ligo gcd '(2n*2n*3n*11n, 2n*2n*2n*3n*3n*5n*7n)'
# Outputs: +12
```
<!--CameLIGO-->
`Loop.fold_while` is a fold operation that takes an initial value of a certain type
and then iterates on it until a condition is reached. The auxillary function
that does the fold returns either boolean true or boolean false to indicate
whether the fold should continue or not. The initial value must match the input
parameter of the auxillary function, and the auxillary should return type `(bool * input)`.
CameLIGO is a functional language where user-defined values are
constant, therefore it makes no sense in CameLIGO to feature loops,
which we understand as syntactic constructs where the state of a
stopping condition is mutated, as with "while" loops in PascaLIGO.
`continue` and `stop` are provided as syntactic sugar for the return values.
Instead, CameLIGO features a *fold operation* as a predefined function
named `Loop.fold_while`. It takes an initial value of a certain type,
called an *accumulator*, and repeatedly calls a given function, called
*iterated function*, that takes that accumulator and returns the next
value of the accumulator, until a condition is met and the fold stops
with the final value of the accumulator. The iterated function needs
to have a special type: if the type of the accumulator is `t`, then it
must have the type `bool * t` (not simply `t`). It is the boolean
value that denotes whether the stopping condition has been reached.
```cameligo
let aux (i: int) : bool * int =
if i < 100 then continue (i + 1) else stop i
Here is how to compute the greatest common divisors of two natural
number by means of Euclid's algorithm:
let counter_simple (n: int) : int =
Loop.fold_while aux n
```cameligo group=a
let iter (x,y : nat * nat) : bool * (nat * nat) =
if y = 0n then false, (x,y) else true, (y, x mod y)
let gcd (x,y : nat * nat) : nat =
let x,y = if x < y then y,x else x,y in
let x,y = Loop.fold_while iter (x,y)
in x
```
To ease the writing and reading of the iterated functions (here,
`iter`), two predefined functions are provided: `continue` and `stop`:
```cameligo group=a
let iter (x,y : nat * nat) : bool * (nat * nat) =
if y = 0n then stop (x,y) else continue (y, x mod y)
let gcd (x,y : nat * nat) : nat =
let x,y = if x < y then y,x else x,y in
let x,y = Loop.fold_while iter (x,y)
in x
```
You can call the function `gcd` defined above using the LIGO compiler
like so:
```shell
ligo run-function
gitlab-pages/docs/language-basics/src/loops/gcd.mligo gcd (2n*2n*3n*11n, 2n*2n*2n*3n*3n*5n*7n)'
# Outputs: +12
```
<!--ReasonLIGO-->
`Loop.fold_while` is a fold operation that takes an initial value of a certain type
and then iterates on it until a condition is reached. The auxillary function
that does the fold returns either boolean true or boolean false to indicate
whether the fold should continue or not. The initial value must match the input
parameter of the auxillary function, and the auxillary should return type `(bool, input)`.
ReasonLIGO is a functional language where user-defined values are
constant, therefore it makes no sense in ReasonLIGO to feature loops,
which we understand as syntactic constructs where the state of a
stopping condition is mutated, as with "while" loops in PascaLIGO.
`continue` and `stop` are provided as syntactic sugar for the return values.
Instead, ReasonLIGO features a *fold operation* as a predefined
function named `Loop.fold_while`. It takes an initial value of a
certain type, called an *accumulator*, and repeatedly calls a given
function, called *iterated function*, that takes that accumulator and
returns the next value of the accumulator, until a condition is met
and the fold stops with the final value of the accumulator. The
iterated function needs to have a special type: if the type of the
accumulator is `t`, then it must have the type `bool * t` (not simply
`t`). It is the boolean value that denotes whether the stopping
condition has been reached.
```reasonligo
let aux = (i: int): (bool, int) =>
if (i < 100) {
continue(i + 1);
} else {
stop(i);
};
Here is how to compute the greatest common divisors of two natural
number by means of Euclid's algorithm:
let counter_simple = (n: int): int => Loop.fold_while(aux, n);
```reasonligo group=a
let iter = ((x,y) : (nat, nat)) : (bool, (nat, nat)) =>
if (y == 0n) { (false, (x,y)); } else { (true, (y, x mod y)); };
let gcd = ((x,y) : (nat, nat)) : nat => {
let (x,y) = if (x < y) { (y,x); } else { (x,y); };
let (x,y) = Loop.fold_while (iter, (x,y));
x
};
```
To ease the writing and reading of the iterated functions (here,
`iter`), two predefined functions are provided: `continue` and `stop`:
```reasonligo group=b
let iter = ((x,y) : (nat, nat)) : (bool, (nat, nat)) =>
if (y == 0n) { stop ((x,y)); } else { continue ((y, x mod y)); };
let gcd = ((x,y) : (nat, nat)) : nat => {
let (x,y) = if (x < y) { (y,x); } else { (x,y); };
let (x,y) = Loop.fold_while (iter, (x,y));
x
};
```
<!--END_DOCUSAURUS_CODE_TABS-->
## For Loop
## Bounded Loops
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
In addition to general loops, PascaLIGO features a specialised kind of
*loop to iterate over bounded intervals*. These loops are familiarly
known as "for loops" and they have the form `for <variable assignment> to
<upper bound> <block>`, which is familiar for programmers of
imperative languages.
To iterate over a range of integers you use a loop of the form `for <variable assignment> to <integer> <block>`.
Consider how to sum integers from `0` to `n`:
```pascaligo
function for_sum (var n : nat) : int is block {
var acc : int := 0 ;
for i := 1 to int(n)
begin
acc := acc + i;
end
```pascaligo group=c
function sum (var n : nat) : int is block {
var acc : int := 0;
for i := 1 to int (n) block {
acc := acc + i
}
} with acc
```
<!--END_DOCUSAURUS_CODE_TABS-->
(Please do not use that function: there exists a closed form formula.)
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
PascaLIGO for loops can also iterate through the contents of a collection. This is
done with a loop of the form `for <element var> in <collection type> <collection var> <block>`.
```pascaligo
function for_collection_list (var nee : unit) : (int * string) is block {
var acc : int := 0;
var st : string := "to";
var mylist : list(int) := list 1; 1; 1 end;
for x in list mylist
begin
acc := acc + x;
st := st ^ "to";
end
} with (acc, st)
You can call the function `sum` defined above using the LIGO compiler
like so:
```shell
ligo run-function
gitlab-pages/docs/language-basics/src/loops/sum.ligo sum 7n
# Outputs: 28
```
<!--END_DOCUSAURUS_CODE_TABS-->
PascaLIGO "for" loops can also iterate through the contents of a
collection, that is, a list, a set or a map. This is done with a loop
of the form `for <element var> in <collection type> <collection var>
<block>`, where `<collection type` is any of the following keywords:
`list`, `set` or `map`.
Here is an example where the integers in a list are summed up.
```pascaligo group=d
function sum_list (var l : list (int)) : int is block {
var total : int := 0;
for i in list l block {
total := total + i
}
} with total
```
You can call the function `sum_list` defined above using the LIGO compiler
like so:
```shell
ligo run-function
gitlab-pages/docs/language-basics/src/loops/collection.ligo sum_list
'list [1;2;3]'
# Outputs: 6
```
Here is an example where the integers in a set are summed up.
```pascaligo=e
function sum_set (var s : set (int)) : int is block {
var total : int := 0;
for i in set s block {
total := total + i
}
} with total
```
You can call the function `sum_set` defined above using the LIGO compiler
like so:
```shell
ligo run-function
gitlab-pages/docs/language-basics/src/loops/collection.ligo sum_set
'set [1;2;3]'
# Outputs: 6
```
Loops over maps are actually loops over the bindings of the map, that
is, a pair key-value noted `key -> value` (or any other
variables). Give a map from strings to integers, here is how to sum
all the integers and concatenate all the strings.
You can call the function `sum_map` defined above using the LIGO compiler
like so:
```shell
ligo run-function
gitlab-pages/docs/language-basics/src/loops/collection.ligo sum_map
'map ["1"->1; "2"->2; "3"->3]'
# Outputs: ( "123", 6 )
```

1294
gitlab-pages/docs/language-basics/maps-records.md
View File

File diff suppressed because it is too large Load Diff

279
gitlab-pages/docs/language-basics/math-numbers-tez.md
View File

@ -7,120 +7,151 @@ LIGO offers three built-in numerical types: `int`, `nat` and `tez`.
## Addition
Addition in ligo is acomplished by using the `+` operator. Some type constraints apply; for example you can't add `tez + nat`.
Addition in LIGO is accomplished by means of the `+` infix
operator. Some type constraints apply, for example you cannot add a
value of type `tez` to a value of type `nat`.
In the following example you can find a series of arithmetic operations, including various numerical types. However, some bits of the example won't compile because adding an `int` to a `nat` produces an `int`, not a `nat`. Similiar rules apply for `tez`:
In the following example you can find a series of arithmetic
operations, including various numerical types. However, some bits
remain in comments as they would otherwise not compile, for example,
adding a value of type `int` to a value of type `tez` is invalid. Note
that adding an integer to a natural number produces an integer.
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
<!--PascaLIGO-->
```pascaligo group=a
// int + int produces int
const a: int = 5 + 10;
// nat + int produces int
const b: int = 5n + 10;
// tez + tez produces tez
const c: tez = 5mutez + 10mutez;
// you can't add tez + int or tez + nat, this won't compile
// const d: tez = 5mutez + 10n;
// two nats produce a nat
const e: nat = 5n + 10n;
// nat + int produces an int, this won't compile
// const f: nat = 5n + 10;
const g: int = 1_000_000;
// int + int yields int
const a : int = 5 + 10
// nat + int yields int
const b : int = 5n + 10
// tez + tez yields tez
const c : tez = 5mutez + 10mutez
//tez + int or tez + nat is invalid
// const d : tez = 5mutez + 10n
// two nats yield a nat
const e : nat = 5n + 10n
// nat + int yields an int: invalid
// const f : nat = 5n + 10;
const g : int = 1_000_000
```
> Pro tip: you can use underscores for readability when defining large numbers
> Pro tip: you can use underscores for readability when defining large
> numbers:
>
>```pascaligo
>const g: int = 1_000_000;
> const sum : tez = 100_000mutez
>```
<!--CameLIGO-->
```cameligo group=a
// int + int produces int
let a: int = 5 + 10
// nat + int produces int
let b: int = 5n + 10
// tez + tez produces tez
let c: tez = 5mutez + 10mutez
// you can't add tez + int or tez + nat, this won't compile
// const d: tez = 5mutez + 10n
// two nats produce a nat
let e: nat = 5n + 10n
// nat + int produces an int, this won't compile
// const f: nat = 5n + 10
let g: int = 1_000_000
// int + int yields int
let a : int = 5 + 10
// nat + int yields int
let b : int = 5n + 10
// tez + tez yields tez
let c : tez = 5mutez + 10mutez
// tez + int or tez + nat is invalid
// const d : tez = 5mutez + 10n
// two nats yield a nat
let e : nat = 5n + 10n
// nat + int yields an int: invalid
// const f : nat = 5n + 10
let g : int = 1_000_000
```
> Pro tip: you can use underscores for readability when defining large numbers
> Pro tip: you can use underscores for readability when defining large
> numbers:
>
>```cameligo
>let g: int = 1_000_000;
>let sum : tez = 100_000mutez
>```
<!--ReasonLIGO-->
```reasonligo group=a
(* int + int produces int *)
let a: int = 5 + 10;
(* nat + int produces int *)
let b: int = 5n + 10;
(* tez + tez produces tez *)
let c: tez = 5mutez + 10mutez;
(* you can't add tez + int or tez + nat, this won't compile:
let d: tez = 5mutez + 10n; *)
(* two nats produce a nat *)
let e: nat = 5n + 10n;
(* nat + int produces an int, this won't compile:
let f: nat = 5n + 10; *)
let g: int = 1_000_000;
// int + int yields int
let a : int = 5 + 10;
// nat + int yields int
let b : int = 5n + 10;
// tez + tez yields tez
let c : tez = 5mutez + 10mutez;
// tez + int or tez + nat is invalid:
// let d : tez = 5mutez + 10n;
// two nats yield a nat
let e : nat = 5n + 10n;
// nat + int yields an int: invalid
// let f : nat = 5n + 10;
let g : int = 1_000_000;
```
> Pro tip: you can use underscores for readability when defining large numbers
>
> Pro tip: you can use underscores for readability when defining large
> numbers:
>```reasonligo
>let g: int = 1_000_000;
>let sum : tex = 100_000mutez;
>```
<!--END_DOCUSAURUS_CODE_TABS-->
## Subtraction
The simpliest substraction looks like this:
Subtraction looks as follows.
> ⚠️ Even when subtracting two `nats`, the result is an `int`
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
<!--PascaLIGO-->
```pascaligo group=b
const a: int = 5 - 10;
// substraction of two nats, yields an int
const b: int = 5n - 2n;
// won't compile, result is an int, not a nat
// const c: nat = 5n - 2n;
const d: tez = 5mutez - 1mutez;
const a : int = 5 - 10
// Subtraction of two nats yields an int
const b : int = 5n - 2n
// Therefore the following is invalid
// const c : nat = 5n - 2n
const d : tez = 5mutez - 1mutez
```
<!--CameLIGO-->
```cameligo group=b
let a: int = 5 - 10
// substraction of two nats, yields an int
let b: int = 5n - 2n
// won't compile, result is an int, not a nat
// const c: nat = 5n - 2n
let d: tez = 5mutez - 1mutez
let a : int = 5 - 10
// Subtraction of two nats yields an int
let b : int = 5n - 2n
// Therefore the following is invalid
// const c : nat = 5n - 2n
let d : tez = 5mutez - 1mutez
```
<!--ReasonLIGO-->
```reasonligo group=b
let a: int = 5 - 10;
(* substraction of two nats, yields an int *)
let b: int = 5n - 2n;
(* won't compile, result is an int, not a nat *)
(* let c: nat = 5n - 2n; *)
let d: tez = 5mutez - 1mutez;
let a : int = 5 - 10;
// Subtraction of two nats yields an int
let b : int = 5n - 2n;
// Therefore the following is invalid
// let c : nat = 5n - 2n;
let d : tez = 5mutez - 1mutez;
```
<!--END_DOCUSAURUS_CODE_TABS-->
@ -131,91 +162,109 @@ let d: tez = 5mutez - 1mutez;
You can multiply values of the same type, such as:
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
<!--PascaLIGO-->
```pascaligo group=c
const a: int = 5 * 5;
const b: nat = 5n * 5n;
// you can also multiply `nat` and `tez`
const c: tez = 5n * 5mutez;
const a : int = 5 * 5
const b : nat = 5n * 5n
// You can also multiply `nat` and `tez` in any order
const c : tez = 5n * 5mutez;
```
<!--CameLIGO-->
```cameligo group=c
let a: int = 5 * 5
let b: nat = 5n * 5n
// you can also multiply `nat` and `tez`
let c: tez = 5n * 5mutez
let a : int = 5 * 5
let b : nat = 5n * 5n
// You can also multiply `nat` and `tez` in any order
let c : tez = 5n * 5mutez
```
<!--ReasonLIGO-->
```reasonligo group=c
let a: int = 5 * 5;
let b: nat = 5n * 5n;
(* you can also multiply `nat` and `tez` *)
let c: tez = 5n * 5mutez;
let a : int = 5 * 5;
let b : nat = 5n * 5n;
// You can also multiply `nat` and `tez` in any order
let c : tez = 5n * 5mutez;
```
<!--END_DOCUSAURUS_CODE_TABS-->
## Division
In LIGO you can divide `int`, `nat`, and `tez`. Here's how:
In LIGO you can divide `int`, `nat`, and `tez`. Here is how:
> ⚠️ Division of two `tez` values results into a `nat`
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
<!--PascaLIGO-->
```pascaligo group=d
const a: int = 10 / 3;
const b: nat = 10n / 3n;
const c: nat = 10mutez / 3mutez;
const a : int = 10 / 3
const b : nat = 10n / 3n
const c : nat = 10mutez / 3mutez
```
<!--CameLIGO-->
```cameligo group=d
let a: int = 10 / 3
let b: nat = 10n / 3n
let c: nat = 10mutez / 3mutez
let a : int = 10 / 3
let b : nat = 10n / 3n
let c : nat = 10mutez / 3mutez
```
<!--ReasonLIGO-->
```reasonligo group=d
let a: int = 10 / 3;
let b: nat = 10n / 3n;
let c: nat = 10mutez / 3mutez;
let a : int = 10 / 3;
let b : nat = 10n / 3n;
let c : nat = 10mutez / 3mutez;
```
<!--END_DOCUSAURUS_CODE_TABS-->
## From `int` to `nat` and back
You can *cast* an `int` to a `nat` and vice versa, here's how:
You can *cast* an `int` to a `nat` and vice versa. Here is how:
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
<!--PascaLIGO-->
```pascaligo group=e
const a: int = int(1n);
const b: nat = abs(1);
const a : int = int (1n)
const b : nat = abs (1)
```
<!--END_DOCUSAURUS_CODE_TABS-->
## Check if a value is a `nat`
You can check if a value is a `nat`, by using a syntax specific built-in function, which accepts an `int` and returns an `option(nat)`, more specifically `Some(nat)` if the provided integer is a natural number, and `None` otherwise:
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
```pascaligo
const its_a_nat: option(nat) = is_nat(1)
<!--CameLIGO-->
```cameligo group=e
let a : int = int (1n)
let b : nat = abs (1)
```
<!--ReasonLIGO-->
```reasonligo group=e
let a: int = int(1n);
let b: nat = abs(1);
let a : int = int (1n);
let b : nat = abs (1);
```
<!--END_DOCUSAURUS_CODE_TABS-->
<!--END_DOCUSAURUS_CODE_TABS-->
## Checking a `nat`
You can check if a value is a `nat` by using a predefined cast
function which accepts an `int` and returns an optional `nat`: if the
result is not `None`, then the provided integer was indeed a natural
number, and not otherwise.
<!--DOCUSAURUS_CODE_TABS-->
<!--PascaLIGO-->
```pascaligo group=e
const is_a_nat : option (nat) = is_nat (1)
```
<!--CameLIGO-->
```cameligo group=e
let is_a_nat : nat option = Michelson.is_nat (1)
```
<!--ReasonLIGO-->
```reasonligo group=e
let is_a_nat : option (nat) = Michelson.is_nat (1);
```
<!--END_DOCUSAURUS_CODE_TABS-->

823
gitlab-pages/docs/language-basics/sets-lists-tuples.md
View File

@ -1,342 +1,735 @@
---
id: sets-lists-tuples
title: Sets, Lists, Tuples
title: Tuples, Lists, Sets
---
Apart from complex data types such as `maps` and `records`, ligo also
exposes `sets`, `lists` and `tuples`.
Apart from complex data types such as `maps` and `records`, LIGO also
features `tuples`, `lists` and `sets`.
> ⚠️ Make sure to pick the appropriate data type for your use case; it carries not only semantic but also gas related costs.
## Tuples
## Sets
Tuples gather a given number of values in a specific order and those
values, called *components*, can be retrieved by their index
(position). Probably the most common tuple is the *pair*. For
example, if we were storing coordinates on a two dimensional grid we
might use a pair `(x,y)` to store the coordinates `x` and `y`. There
is a *specific order*, so `(y,x)` is not equal to `(x,y)`. The number
of components is part of the type of a tuple, so, for example, we
cannot add an extra component to a pair and obtain a triple of the
same type, so, for instance, `(x,y)` has always a different type from
`(x,y,z)`, whereas `(y,x)` might have the same type as `(x,y)`.
Sets are similar to lists. The main difference is that elements of a
`set` must be *unique*.
Like records, tuple components can be of arbitrary types.
### Defining a set
### Defining Tuples
Unlike [a record](language-basics/maps-records.md), tuple types do not
have to be defined before they can be used. However below we will give
them names by *type aliasing*.
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
```pascaligo group=a
type int_set is set (int);
const my_set : int_set = set 1; 2; 3 end
```pascaligo group=tuple
type full_name is string * string // Alias
const full_name : full_name = ("Alice", "Johnson")
```
<!--CameLIGO-->
```cameligo group=a
type int_set = int set
let my_set : int_set =
Set.add 3 (Set.add 2 (Set.add 1 (Set.empty: int set)))
```cameligo group=tuple
type full_name = string * string // Alias
let full_name : full_name = ("Alice", "Johnson") // Optional parentheses
```
<!--ReasonLIGO-->
```reasonligo group=a
type int_set = set (int);
let my_set : int_set =
Set.add (3, Set.add (2, Set.add (1, Set.empty: set (int))));
```
<!--END_DOCUSAURUS_CODE_TABS-->
```reasonligo group=tuple
type full_name = (string, string); // Alias
### Empty sets
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
```pascaligo group=a
const my_set: int_set = set end
const my_set_2: int_set = set_empty
```
<!--CameLIGO-->
```cameligo group=a
let my_set: int_set = (Set.empty: int set)
```
<!--ReasonLIGO-->
```reasonligo group=a
let my_set: int_set = (Set.empty: set (int));
```
<!--END_DOCUSAURUS_CODE_TABS-->
### Checking if set contains an element
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
```pascaligo group=a
const contains_three : bool = my_set contains 3
// or alternatively
const contains_three_fn: bool = set_mem (3, my_set);
```
<!--CameLIGO-->
```cameligo group=a
let contains_three: bool = Set.mem 3 my_set
```
<!--ReasonLIGO-->
```reasonligo group=a
let contains_three: bool = Set.mem(3, my_set);
let full_name : full_name = ("Alice", "Johnson");
```
<!--END_DOCUSAURUS_CODE_TABS-->
### Obtaining the size of a set
### Accessing Components
Accessing the components of a tuple in OCaml is achieved by
[pattern matching](language-basics/unit-option-pattern-matching.md). LIGO
currently supports tuple patterns only in the parameters of functions,
not in pattern matching. However, we can access components by their
position in their tuple, which cannot be done in OCaml.
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
```pascaligo group=a
const set_size: nat = size (my_set)
```
<!--CameLIGO-->
```cameligo group=a
let set_size: nat = Set.size my_set
```
<!--PascaLIGO-->
<!--ReasonLIGO-->
```reasonligo group=a
let set_size: nat = Set.size (my_set);
```
Tuple components are one-indexed like so:
<!--END_DOCUSAURUS_CODE_TABS-->
### Modifying a set
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
```pascaligo group=a
const larger_set: int_set = set_add(4, my_set);
const smaller_set: int_set = set_remove(3, my_set);
```pascaligo group=tuple
const first_name : string = full_name.1;
```
<!--CameLIGO-->
```cameligo group=a
let larger_set: int_set = Set.add 4 my_set
let smaller_set: int_set = Set.remove 3 my_set
Tuple elements are zero-indexed and accessed like so:
```cameligo group=tuple
let first_name : string = full_name.0
```
<!--ReasonLIGO-->
```reasonligo group=a
let larger_set: int_set = Set.add(4, my_set);
let smaller_set: int_set = Set.remove(3, my_set);
Tuple components are one-indexed like so:
```reasonligo group=tuple
let first_name : string = full_name[1];
```
<!--END_DOCUSAURUS_CODE_TABS-->
### Folding a set
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
```pascaligo group=a
function sum(const result: int; const i: int): int is result + i;
// Outputs 6
const sum_of_a_set: int = set_fold(sum, my_set, 0);
```
<!--CameLIGO-->
```cameligo group=a
let sum (result, i: int * int) : int = result + i
let sum_of_a_set: int = Set.fold sum my_set 0
```
<!--ReasonLIGO-->
```reasonligo group=a
let sum = (result_i: (int, int)): int => result_i[0] + result_i[1];
let sum_of_a_set: int = Set.fold(sum, my_set, 0);
```
<!--END_DOCUSAURUS_CODE_TABS-->
## Lists
Lists are similar to sets, but their elements don't need to be unique and they don't offer the same range of built-in functions.
Lists are linear collections of elements of the same type. Linear
means that, in order to reach an element in a list, we must visit all
the elements before (sequential access). Elements can be repeated, as
only their order in the collection matters. The first element is
called the *head*, and the sub-list after the head is called the
*tail*. For those familiar with algorithmic data structure, you can
think of a list a *stack*, where the top is written on the left.
> 💡 Lists are useful when returning operations from a smart contract's entrypoint.
> 💡 Lists are useful when returning operations from a smart
> contract's entrypoint.
### Defining a list
### Defining Lists
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
```pascaligo group=b
type int_list is list(int);
const my_list: int_list = list
1;
2;
3;
end
<!--PascaLIGO-->
```pascaligo group=lists
const my_list : list (int) = list [1; 2; 2] // The head is 1
```
<!--CameLIGO-->
```cameligo group=b
type int_list = int list
let my_list: int_list = [1; 2; 3]
```cameligo group=lists
let my_list : int list = [1; 2; 2] // The head is 1
```
<!--ReasonLIGO-->
```reasonligo group=b
type int_list = list(int);
let my_list: int_list = [1, 2, 3];
```reasonligo group=lists
let my_list : list (int) = [1, 2, 2]; // The head is 1
```
<!--END_DOCUSAURUS_CODE_TABS-->
### Appending an element to a list
### Adding to Lists
Lists can be augmented by adding an element before the head (or, in
terms of stack, by *pushing an element on top*). This operation is
usually called *consing* in functional languages.
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
```pascaligo group=b
const larger_list: int_list = cons(4, my_list);
const even_larger_list: int_list = 5 # larger_list;
<!--PascaLIGO-->
In PascaLIGO, the *cons operator* is infix and noted `#`. It is not
symmetric: on the left lies the element to cons, and, on the right, a
list on which to cons. (The symbol is helpfully asymmetric to remind
you of that.)
```pascaligo group=lists
const larger_list : list (int) = 5 # my_list // [5;1;2;2]
```
<!--CameLIGO-->
```cameligo group=b
let larger_list: int_list = 4 :: my_list
(* CameLIGO doesn't have a List.cons *)
In CameLIGO, the *cons operator* is infix and noted `::`. It is not
symmetric: on the left lies the element to cons, and, on the right, a
list on which to cons.
```cameligo group=lists
let larger_list : int list = 5 :: my_list // [5;1;2;2]
```
<!--ReasonLIGO-->
```reasonligo group=b
let larger_list: int_list = [4, ...my_list];
(* ReasonLIGO doesn't have a List.cons *)
```
In ReasonLIGO, the *cons operator* is infix and noted `, ...`. It is
not symmetric: on the left lies the element to cons, and, on the
right, a list on which to cons.
```reasonligo group=lists
let larger_list : list (int) = [5, ...my_list]; // [5,1,2,2]
```
<!--END_DOCUSAURUS_CODE_TABS-->
<br/>
> 💡 Lists can be iterated, folded or mapped to different values. You can find additional examples [here](https://gitlab.com/ligolang/ligo/tree/dev/src/test/contracts) and other built-in operators [here](https://gitlab.com/ligolang/ligo/blob/dev/src/passes/operators/operators.ml#L59)
> 💡 Lists can be iterated, folded or mapped to different values. You
> can find additional examples
> [here](https://gitlab.com/ligolang/ligo/tree/dev/src/test/contracts)
> and other built-in operators
> [here](https://gitlab.com/ligolang/ligo/blob/dev/src/passes/operators/operators.ml#L59)
### Mapping of a list
### Functional Iteration over Lists
A *functional iterator* is a function that traverses a data structure
and calls in turn a given function over the elements of that structure
to compute some value. Another approach is possible in PascaLIGO:
*loops* (see the relevant section).
There are three kinds of functional iterations over LIGO maps: the
*iterated operation*, the *map operation* (not to be confused with the
*map data structure*) and the *fold operation*.
#### Iterated Operation
The first, the *iterated operation*, is an iteration over the map with
no return value: its only use is to produce side-effects. This can be
useful if for example you would like to check that each value inside
of a map is within a certain range, and fail with an error otherwise.
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
```pascaligo group=b
function increment(const i: int): int is block { skip } with i + 1;
// Creates a new list with elements incremented by 1
const incremented_list: int_list = list_map(increment, even_larger_list);
<!--PascaLIGO-->
In PascaLIGO, the predefined functional iterator implementing the
iterated operation over lists is called `list_iter`.
In the following example, a list is iterated to check that all its
elements (integers) are greater than `3`:
```pascaligo group=lists
function iter_op (const l : list (int)) : unit is
block {
function iterated (const i : int) : unit is
if i > 2 then Unit else (failwith ("Below range.") : unit)
} with list_iter (iterated, l)
```
> The iterated function must be pure, that is, it cannot mutate
> variables.
<!--CameLIGO-->
```cameligo group=b
let increment (i: int) : int = i + 1
(* Creates a new list with elements incremented by 1 *)
let incremented_list: int_list = List.map increment larger_list
```
In CameLIGO, the predefined functional iterator implementing the
iterated operation over lists is called `List.iter`.
In the following example, a list is iterated to check that all its
elements (integers) are greater than `3`:
```cameligo group=lists
let iter_op (l : int list) : unit =
let predicate = fun (i : int) -> assert (i > 3)
in List.iter predicate l
```
<!--ReasonLIGO-->
```reasonligo group=b
let increment = (i: int): int => i + 1;
(* Creates a new list with elements incremented by 1 *)
let incremented_list: int_list = List.map(increment, larger_list);
In ReasonLIGO, the predefined functional iterator implementing the
iterated operation over lists is called `List.iter`.
In the following example, a list is iterated to check that all its
elements (integers) are greater than `3`:
```reasonligo group=lists
let iter_op = (l : list (int)) : unit => {
let predicate = (i : int) => assert (i > 3);
List.iter (predicate, l);
};
```
<!--END_DOCUSAURUS_CODE_TABS-->
### Folding of a list:
#### Map Operation
We may want to change all the elements of a given list by applying to
them a function. This is called a *map operation*, not to be confused
with the map data structure.
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
```pascaligo group=b
function sum(const result: int; const i: int): int is block { skip } with result + i;
// Outputs 6
const sum_of_a_list: int = list_fold(sum, my_list, 0);
<!--PascaLIGO-->
In PascaLIGO, the predefined functional iterator implementing the map
operation over lists is called `list_map` and is used as follows:
```pascaligo group=lists
function increment (const i : int): int is i + 1
// Creates a new list with all elements incremented by 1
const plus_one : list (int) = list_map (increment, larger_list)
```
<!--CameLIGO-->
```cameligo group=b
let sum (result, i: int * int) : int = result + i
// Outputs 6
let sum_of_a_list: int = List.fold sum my_list 0
In CameLIGO, the predefined functional iterator implementing the map
operation over lists is called `List.map` and is used as follows:
```cameligo group=lists
let increment (i : int) : int = i + 1
// Creates a new list with all elements incremented by 1
let plus_one : int list = List.map increment larger_list
```
<!--ReasonLIGO-->
```reasonligo group=b
In ReasonLIGO, the predefined functional iterator implementing the map
operation over lists is called `List.map` and is used as follows:
```reasonligo group=lists
let increment = (i : int) : int => i + 1;
// Creates a new list with all elements incremented by 1
let plus_one : list (int) = List.map (increment, larger_list);
```
<!--END_DOCUSAURUS_CODE_TABS-->
#### Fold Operation
A *fold operation* is the most general of iterations. The folded
function takes two arguments: an *accumulator* and the structure
*element* at hand, with which it then produces a new accumulator. This
enables having a partial result that becomes complete when the
traversal of the data structure is over.
<!--DOCUSAURUS_CODE_TABS-->
<!--PascaLIGO-->
In PascaLIGO, the predefined functional iterator implementing the fold
operation over lists is called `list_fold` and is used as follows:
```pascaligo group=lists
function sum (const acc : int; const i : int): int is acc + i
const sum_of_elements : int = list_fold (sum, my_list, 0)
```
> The folded function must be pure, that is, it cannot mutate
> variables.
<!--CameLIGO-->
In CameLIGO, the predefined functional iterator implementing the fold
operation over lists is called `List.fold` and is used as follows:
```cameligo group=lists
let sum (acc, i: int * int) : int = acc + i
let sum_of_elements : int = List.fold sum my_list 0
```
<!--ReasonLIGO-->
In ReasonLIGO, the predefined functional iterator implementing the
fold operation over lists is called `List.fold` and is used as follows:
```reasonligo group=lists
let sum = ((result, i): (int, int)): int => result + i;
(* Outputs 6 *)
let sum_of_a_list: int = List.fold(sum, my_list, 0);
let sum_of_elements : int = List.fold (sum, my_list, 0);
```
<!--END_DOCUSAURUS_CODE_TABS-->
## Sets
## Tuples
Sets are unordered collections of values of the same type, like lists
are ordered collections. Like the mathematical sets and lists, sets
can be empty and, if not, elements of sets in LIGO are *unique*,
whereas they can be repeated in a list.
Tuples are used to store related data that has a **specific order** and **defined
length** without the need for named fields or a dedicated type identity. Probably
the most common tuple is a pair of type `(a, b)`. For example, if we were storing
coordinates on a two dimensional grid we might use a pair tuple of type `int * int`
to store the coordinates x and y. There is a **specific order** because x and y must
always stay in the same location within the tuple for the data to make sense. There is
also a **defined length** because the tuple pair can only ever have two elements,
if we added a third dimension `z` its type would be incompatible with that of the
pair tuple.
Like records, tuples can have members of arbitrary types in the same structure.
### Defining a tuple
Unlike [a record](language-basics/maps-records.md), tuple types do not have to be
defined before they can be used. However below we will give them names for the
sake of illustration.
### Empty Sets
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
```pascaligo group=c
type full_name is string * string;
const full_name: full_name = ("Alice", "Johnson");
<!--PascaLIGO-->
In PascaLIGO, the notation for sets is similar to that for lists,
except the keyword `set` is used before:
```pascaligo group=sets
const my_set : set (int) = set []
```
<!--CameLIGO-->
In CameLIGO, the empty set is denoted by the predefined value
`Set.empty`.
```cameligo group=sets
let my_set : int set = Set.empty
```
<!--ReasonLIGO-->
In CameLIGO, the empty set is denoted by the predefined value
`Set.empty`.
```reasonligo group=sets
let my_set : set (int) = Set.empty;
```
<!--END_DOCUSAURUS_CODE_TABS-->
### Non-empty Sets
<!--DOCUSAURUS_CODE_TABS-->
<!--PascaLIGO-->
In PascaLIGO, the notation for sets is similar to that for lists,
except the keyword `set` is used before:
```pascaligo group=sets
const my_set : set (int) = set [3; 2; 2; 1]
```
You can check that `2` is not repeated in `my_set` by using the LIGO
compiler like this (the output will sort the elements of the set, but
that order is not significant for the compiler):
```shell
ligo evaluate-value
gitlab-pages/docs/language-basics/src/sets-lists-tuples/sets.ligo my_set
# Outputs: { 3 ; 2 ; 1 }
```
<!--CameLIGO-->
```cameligo group=c
type full_name = string * string
(* The parenthesis here are optional *)
let full_name: full_name = ("Alice", "Johnson")
In CameLIGO, there is no predefined syntactic construct for sets: you
must build your set by adding to the empty set. (This is the way in
OCaml.)
```cameligo group=sets
let my_set : int set =
Set.add 3 (Set.add 2 (Set.add 2 (Set.add 1 (Set.empty : int set))))
```
You can check that `2` is not repeated in `my_set` by using the LIGO
compiler like this (the output will sort the elements of the set, but
that order is not significant for the compiler):
```shell
ligo evaluate-value
gitlab-pages/docs/language-basics/src/sets-lists-tuples/sets.mligo my_set
# Outputs: { 3 ; 2 ; 1 }
```
<!--ReasonLIGO-->
```reasonligo group=c
type full_name = (string, string);
(* The parenthesis here are optional *)
let full_name: full_name = ("Alice", "Johnson");
In ReasonLIGO, there is no predefined syntactic construct for sets:
you must build your set by adding to the empty set. (This is the way
in OCaml.)
```reasonligo group=sets
let my_set : set (int) =
Set.add (3, Set.add (2, Set.add (2, Set.add (1, Set.empty : set (int)))));
```
You can check that `2` is not repeated in `my_set` by using the LIGO
compiler like this (the output will sort the elements of the set, but
that order is not significant for the compiler):
```shell
ligo evaluate-value
gitlab-pages/docs/language-basics/src/sets-lists-tuples/sets.religo my_set
# Outputs: { 3 ; 2 ; 1 }
```
<!--END_DOCUSAURUS_CODE_TABS-->
### Accessing an element in a tuple
The traditional way to access the elements of a tuple in OCaml is through
[a pattern match](language-basics/unit-option-pattern-matching.md). LIGO **does
not** currently support tuple patterns in its syntaxes.
However, it is possible to access LIGO tuples by their position.
### Set Membership
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
<!--PascaLIGO-->
Tuple elements are one-indexed and accessed like so:
PascaLIGO features a special keyword `contains` that operates like an
infix operator checking membership in a set.
```pascaligo group=c
const first_name: string = full_name.1;
```pascaligo group=sets
const contains_3 : bool = my_set contains 3
```
<!--Cameligo-->
<!--CameLIGO-->
Tuple elements are zero-indexed and accessed like so:
In CameLIGO, the predefined predicate `Set.mem` tests for membership
in a set as follows:
```cameligo group=c
let first_name: string = full_name.0
```cameligo group=sets
let contains_3 : bool = Set.mem 3 my_set
```
<!--ReasonLIGO-->
```reasonligo group=c
let first_name: string = full_name[1];
In ReasonLIGO, the predefined predicate `Set.mem` tests for membership
in a set as follows:
```reasonligo group=sets
let contains_3 : bool = Set.mem (3, my_set);
```
<!--END_DOCUSAURUS_CODE_TABS-->
### Cardinal
<!--DOCUSAURUS_CODE_TABS-->
<!--PascaLIGO-->
In PascaLIGO, the predefined function `size` returns the number of
elements in a given set as follows:
```pascaligo group=sets
const set_size : nat = size (my_set)
```
<!--CameLIGO-->
In CameLIGO, the predefined function `Set.size` returns the number of
elements in a given set as follows:
```cameligo group=sets
let set_size : nat = Set.size my_set
```
<!--ReasonLIGO-->
In ReasonLIGO, the predefined function `Set.size` returns the number
of elements in a given set as follows:
```reasonligo group=sets
let set_size : nat = Set.size (my_set);
```
<!--END_DOCUSAURUS_CODE_TABS-->
### Updating Sets
<!--DOCUSAURUS_CODE_TABS-->
<!--PascaLIGO-->
In PascaLIGO, there are two ways to update a set, that is to add or
remove from it. Either we create a new set from the given one, or we
modify it in-place. First, let us consider the former way
```pascaligo group=sets
const larger_set : set (int) = set_add (4, my_set)
const smaller_set : set (int) = set_remove (3, my_set)
```
If we are in a block, we can use an instruction to modify the set
bound to a given variable. This is called a *patch*. It is only
possible to add elements by means of a patch, not remove any: it is
the union of two sets.
In the following example, the parameter set `s` of function `update`
is augmented (as the `with s` shows) to include `4` and `7`, that is,
this instruction is equivalent to perform the union of two sets, one
that is modified in-place, and the other given as a literal
(extensional definition).
```pascaligo group=sets
function update (var s : set (int)) : set (int) is block {
patch s with set [4; 7]
} with s
const new_set : set (int) = update (my_set)
```
<!--CameLIGO-->
In CameLIGO, we update a given set by creating another one, with or
without some elements.
```cameligo group=sets
let larger_set : int set = Set.add 4 my_set
let smaller_set : int set = Set.remove 3 my_set
```
<!--ReasonLIGO-->
In ReasonLIGO, we update a given set by creating another one, with or
without some elements.
```reasonligo group=sets
let larger_set : set (int) = Set.add (4, my_set);
let smaller_set : set (int) = Set.remove (3, my_set);
```
<!--END_DOCUSAURUS_CODE_TABS-->
### Functional Iteration over Sets
A *functional iterator* is a function that traverses a data structure
and calls in turn a given function over the elements of that structure
to compute some value. Another approach is possible in PascaLIGO:
*loops* (see the relevant section).
There are three kinds of functional iterations over LIGO maps: the
*iterated operation*, the *map operation* (not to be confused with the
*map data structure*) and the *fold operation*.
#### Iterated Operation
The first, the *iterated operation*, is an iteration over the map with
no return value: its only use is to produce side-effects. This can be
useful if for example you would like to check that each value inside
of a map is within a certain range, and fail with an error otherwise.
<!--DOCUSAURUS_CODE_TABS-->
<!--PascaLIGO-->
In PascaLIGO, the predefined functional iterator implementing the
iterated operation over sets is called `set_iter`.
In the following example, a set is iterated to check that all its
elements (integers) are greater than `3`:
```pascaligo group=sets
function iter_op (const s : set (int)) : unit is
block {
function iterated (const i : int) : unit is
if i > 2 then Unit else (failwith ("Below range.") : unit)
} with set_iter (iterated, s)
```
> The iterated function must be pure, that is, it cannot mutate
> variables.
<!--CameLIGO-->
In CameLIGO, the predefined functional iterator implementing the
iterated operation over sets is called `Set.iter`.
In the following example, a set is iterated to check that all its
elements (integers) are greater than `3`:
```cameligo group=sets
let iter_op (s : int set) : unit =
let predicate = fun (i : int) -> assert (i > 3)
in Set.iter predicate s
```
<!--ReasonLIGO-->
In ReasonLIGO, the predefined functional iterator implementing the
iterated operation over sets is called `Set.iter`.
In the following example, a set is iterated to check that all its
elements (integers) are greater than `3`:
```reasonligo group=sets
let iter_op = (s : set (int)) : unit => {
let predicate = (i : int) => assert (i > 3);
Set.iter (predicate, s);
};
```
<!--END_DOCUSAURUS_CODE_TABS-->
#### Map Operation
We may want to change all the elements of a given set by applying to
them a function. This is called a *map operation*, not to be confused
with the map data structure.
<!--DOCUSAURUS_CODE_TABS-->
<!--PascaLIGO-->
In PascaLIGO, the predefined functional iterator implementing the map
operation over sets is called `set_map` and is used as follows:
```pascaligo skip
function increment (const i : int): int is i + 1
// Creates a new set with all elements incremented by 1
const plus_one : set (int) = set_map (increment, larger_set)
```
<!--CameLIGO-->
In CameLIGO, the predefined functional iterator implementing the map
operation over sets is called `Set.map` and is used as follows:
```cameligo skip
let increment (i : int) : int = i + 1
// Creates a new set with all elements incremented by 1
let plus_one : int set = Set.map increment larger_set
```
<!--ReasonLIGO-->
In ReasonLIGO, the predefined functional iterator implementing the map
operation over sets is called `Set.map` and is used as follows:
```reasonligo skip
let increment = (i : int) : int => i + 1;
// Creates a new set with all elements incremented by 1
let plus_one : set (int) = Set.map (increment, larger_set);
```
<!--END_DOCUSAURUS_CODE_TABS-->
#### Fold Operation
A *fold operation* is the most general of iterations. The folded
function takes two arguments: an *accumulator* and the structure
*element* at hand, with which it then produces a new accumulator. This
enables having a partial result that becomes complete when the
traversal of the data structure is over.
<!--DOCUSAURUS_CODE_TABS-->
<!--PascaLIGO-->
In PascaLIGO, the predefined functional iterator implementing the fold
operation over sets is called `set_fold` and is used as follows:
```pascaligo group=sets
function sum (const acc : int; const i : int): int is acc + i
const sum_of_elements : int = set_fold (sum, my_set, 0)
```
> The folded function must be pure, that is, it cannot mutate
> variables.
It is possible to use a *loop* over a set as well.
```pascaligo group=sets
function loop (const s : set (int)) : int is block {
var sum : int := 0;
for element in set s block {
sum := sum + element
}
} with sum
```
<!--CameLIGO-->
In CameLIGO, the predefined fold over sets is called `Set.fold`.
```cameligo group=sets
let sum (acc, i : int * int) : int = acc + i
let sum_of_elements : int = Set.fold sum my_set 0
```
<!--ReasonLIGO-->
In ReasonLIGO, the predefined fold over sets is called `Set.fold`.
```reasonligo group=sets
let sum = ((acc, i) : (int, int)) : int => acc + i;
let sum_of_elements : int = Set.fold (sum, my_set, 0);
```
<!--END_DOCUSAURUS_CODE_TABS-->

4
gitlab-pages/docs/language-basics/src/boolean-if-else/cond.ligo Normal file
View File

@ -0,0 +1,4 @@
type magnitude is Small | Large // See variant types
function compare (const n : nat) : magnitude is
if n < 10n then Small (Unit) else Large (Unit)

4
gitlab-pages/docs/language-basics/src/boolean-if-else/cond.mligo Normal file
View File

@ -0,0 +1,4 @@
type magnitude = Small | Large // See variant types
let compare (n : nat) : magnitude =
if n < 10n then Small else Large

4
gitlab-pages/docs/language-basics/src/boolean-if-else/cond.religo Normal file
View File

@ -0,0 +1,4 @@
type magnitude = | Small | Large; // See variant types
let compare = (n : nat) : magnitude =>
if (n < 10n) { Small; } else { Large; };

4
gitlab-pages/docs/language-basics/src/boolean-if-else/if-else.ligo
View File

@ -1,4 +0,0 @@
const min_age: nat = 16n;
function is_adult(const age: nat): bool is
if (age > min_age) then True else False

4
gitlab-pages/docs/language-basics/src/functions/add.ligo
View File

@ -1,4 +0,0 @@
function add(const a: int; const b: int): int is
begin
const result: int = a + b;
end with result;

7
gitlab-pages/docs/language-basics/src/functions/anon.ligo
View File

@ -1,3 +1,4 @@
const increment : (int -> int) = (function (const i : int) : int is i + 1);
// a = 2
const a: int = increment(1);
function increment (const b : int) : int is
(function (const a : int) : int is a + 1) (b)
const a : int = increment (1); // a = 2

2
gitlab-pages/docs/language-basics/src/functions/anon.mligo Normal file
View File

@ -0,0 +1,2 @@
let increment (b : int) : int = (fun (a : int) -> a + 1) b
let a : int = increment 1 // a = 2

2
gitlab-pages/docs/language-basics/src/functions/anon.religo Normal file
View File

@ -0,0 +1,2 @@
let increment = (b : int) : int => ((a : int) : int => a + 1)(b);
let a : int = increment (1); // a = 2

2
gitlab-pages/docs/language-basics/src/functions/blockless.ligo
View File

@ -1 +1 @@
function add(const a: int; const b: int): int is a + b
function add (const a: int; const b: int): int is a + b

1
gitlab-pages/docs/language-basics/src/functions/blockless.mligo Normal file
View File

@ -0,0 +1 @@
let add (a : int) (b : int) : int = a + b

1
gitlab-pages/docs/language-basics/src/functions/blockless.religo Normal file
View File

@ -0,0 +1 @@
let add = ((a, b): (int, int)) : int => a + b;

3
gitlab-pages/docs/language-basics/src/functions/curry.mligo Normal file
View File

@ -0,0 +1,3 @@
let add (a, b : int * int) : int = a + b // Uncurried
let add_curry (a : int) (b : int) : int = add (a,b) // Curried
let increment (b : int) : int = add_curry 1 // Partial application

5
gitlab-pages/docs/language-basics/src/functions/incr_map.ligo Normal file
View File

@ -0,0 +1,5 @@
function increment (const b : int) : int is
(function (const a : int) : int is a + 1) (b)
function incr_map (const l : list (int)) : list (int) is
list_map (function (const i : int) : int is i + 1, l)

4
gitlab-pages/docs/language-basics/src/functions/incr_map.mligo Normal file
View File

@ -0,0 +1,4 @@
let increment (b : int) : int = (fun (a : int) -> a + 1) b
let incr_map (l : int list) : int list =
List.map (fun (i : int) -> i + 1) l

4
gitlab-pages/docs/language-basics/src/functions/incr_map.religo Normal file
View File

@ -0,0 +1,4 @@
let increment = (b : int) : int => ((a : int) : int => a + 1)(b);
let incr_map = (l : list (int)) : list (int) =>
List.map ((i : int) => i + 1, l);

22
gitlab-pages/docs/language-basics/src/loops/collection.ligo Normal file
View File

@ -0,0 +1,22 @@
function sum_list (var l : list (int)) : int is block {
var total : int := 0;
for i in list l block {
total := total + i
}
} with total
function sum_set (var s : set (int)) : int is block {
var total : int := 0;
for i in set s block {
total := total + i
}
} with total
function sum_map (var m : map (string, int)) : string * int is block {
var string_total : string := "";
var int_total : int := 0;
for key -> value in map m block {
string_total := string_total ^ key;
int_total := int_total + value
}
} with (string_total, int_total)

14
gitlab-pages/docs/language-basics/src/loops/gcd.ligo Normal file
View File

@ -0,0 +1,14 @@
function gcd (var x : nat; var y : nat) : nat is block {
if x < y then
block {
const z : nat = x;
x := y; y := z
}
else skip;
var r : nat := 0n;
while y =/= 0n block {
r := x mod y;
x := y;
y := r
}
} with x

7
gitlab-pages/docs/language-basics/src/loops/gcd.mligo Normal file
View File

@ -0,0 +1,7 @@
let iter (x,y : nat * nat) : bool * (nat * nat) =
if y = 0n then stop (x,y) else continue (y, x mod y)
let gcd (x,y : nat * nat) : nat =
let x,y = if x < y then y,x else x,y in
let x,y = Loop.fold_while iter (x,y)
in x

7
gitlab-pages/docs/language-basics/src/loops/gcd.religo Normal file
View File

@ -0,0 +1,7 @@
let iter = ((x,y) : (nat, nat)) : (bool, (nat, nat)) =>
if (y == 0n) { stop ((x,y)); } else { continue ((y, x mod y)); };
let gcd = ((x,y) : (nat, nat)) : nat =>
let (x,y) = if (x < y) { (y,x); } else { (x,y); };
let (x,y) = Loop.fold_while (iter, (x,y));
x;

6
gitlab-pages/docs/language-basics/src/loops/sum.ligo Normal file
View File

@ -0,0 +1,6 @@
function sum (var n : nat) : int is block {
var acc : int := 0;
for i := 1 to int (n) block {
acc := acc + i
}
} with acc

10
gitlab-pages/docs/language-basics/src/maps-records/record_patch.ligo Normal file
View File

@ -0,0 +1,10 @@
type point is record [x : int; y : int; z : int]
type vector is record [dx : int; dy : int]
const origin : point = record [x = 0; y = 0; z = 0]
function xy_translate (var p : point; const vec : vector) : point is
block {
patch p with record [x = p.x + vec.dx];
patch p with record [y = p.y + vec.dy]
} with p

9
gitlab-pages/docs/language-basics/src/maps-records/record_patch2.ligo Normal file
View File

@ -0,0 +1,9 @@
type point is record [x : int; y : int; z : int]
type vector is record [dx : int; dy : int]
const origin : point = record [x = 0; y = 0; z = 0]
function xy_translate (var p : point; const vec : vector) : point is
block {
patch p with record [x = p.x + vec.dx; y = p.y + vec.dy]
} with p

8
gitlab-pages/docs/language-basics/src/maps-records/record_simu.ligo Normal file
View File

@ -0,0 +1,8 @@
type point is record [x : int; y : int; z : int]
type vector is record [dx : int; dy : int]
const origin : point = record [x = 0; y = 0; z = 0]
function xy_translate (var p : point; const vec : vector) : point is block {
const p : point = p with record [x = p.x + vec.dx; y = p.y + vec.dy]
} with p

7
gitlab-pages/docs/language-basics/src/maps-records/record_update.ligo Normal file
View File

@ -0,0 +1,7 @@
type point is record [x : int; y : int; z : int]
type vector is record [dx : int; dy : int]
const origin : point = record [x = 0; y = 0; z = 0]
function xy_translate (var p : point; const vec : vector) : point is
p with record [x = p.x + vec.dx; y = p.y + vec.dy]

7
gitlab-pages/docs/language-basics/src/maps-records/record_update.mligo Normal file
View File

@ -0,0 +1,7 @@
type point = {x : int; y : int; z : int}
type vector = {dx : int; dy : int}
let origin : point = {x = 0; y = 0; z = 0}
let xy_translate (p, vec : point * vector) : point =
{p with x = p.x + vec.dx; y = p.y + vec.dy}

7
gitlab-pages/docs/language-basics/src/maps-records/record_update.religo Normal file
View File

@ -0,0 +1,7 @@
type point = {x : int, y : int, z : int};
type vector = {dx : int, dy : int};
let origin : point = {x : 0, y : 0, z : 0};
let xy_translate = ((p, vec) : (point, vector)) : point =>
{...p, x : p.x + vec.dx, y : p.y + vec.dy};

13
gitlab-pages/docs/language-basics/src/math-numbers-tez/addition.ligo
View File

@ -1,13 +0,0 @@
// int + int produces int
const a: int = 5 + 10;
// nat + int produces int
const b: int = 5n + 10;
// tez + tez produces tez
const c: tez = 5mutez + 10mutez;
// you can't add tez + int or tez + nat, this won't compile
// const d: tez = 5mutez + 10n;
// two nats produce a nat
const e: nat = 5n + 10n;
// nat + int produces an int, this won't compile
// const f: nat = 5n + 10;
const g: int = 1_000_000;

2
gitlab-pages/docs/language-basics/src/math-numbers-tez/casting.ligo
View File

@ -1,2 +0,0 @@
const a: int = int(1n);
const b: nat = abs(1);

5
gitlab-pages/docs/language-basics/src/math-numbers-tez/division.ligo
View File

@ -1,5 +0,0 @@
const a: int = 10 / 3;
const b: nat = 10n / 3n;
const c: nat = 10mutez / 3mutez;
const d: int = 10 / 5 / 2 * 5;

1
gitlab-pages/docs/language-basics/src/math-numbers-tez/isnat.ligo
View File

@ -1 +0,0 @@
const its_a_nat: option(nat) = is_nat(1)

3
gitlab-pages/docs/language-basics/src/math-numbers-tez/multiplication.ligo
View File

@ -1,3 +0,0 @@
const a: int = 5 * 5;
const b: nat = 5n * 5n;
const c: tez = 5n * 5mutez;

6
gitlab-pages/docs/language-basics/src/math-numbers-tez/substraction.ligo
View File

@ -1,6 +0,0 @@
const a: int = 5 - 10;
// substraction of two nats, yields an int
const b: int = 5n - 2n;
// won't compile, result is an int, not a nat
// const c: nat = 5n - 2n;
const d: tez = 5mutez - 1mutez;

0
gitlab-pages/docs/language-basics/src/sets-lists-touples/empty-set.ligo → gitlab-pages/docs/language-basics/src/sets-lists-tuples/empty-set.ligo
View File

12
gitlab-pages/docs/language-basics/src/sets-lists-tuples/lists.ligo Normal file
View File

@ -0,0 +1,12 @@
const my_list : list (int) = list [1; 2; 2] // The head is 1
const larger_list : int_list = 5 # my_list
function increment (const i : int): int is i + 1
// Creates a new list with all elements incremented by 1
const plus_one : list (int) = list_map (increment, larger_list);
function sum (const acc : int; const i : int): int is acc + i
const sum_of_elements : int = list_fold (sum, my_list, 0)

28
gitlab-pages/docs/language-basics/src/sets-lists-tuples/sets.ligo Normal file
View File

@ -0,0 +1,28 @@
type int_set is set (int)
const my_set : int_set = set [3; 2; 2; 1]
const contains_3 : bool = my_set contains 3
const set_size : nat = size (my_set)
const larger_set : int_set = set_add (4, my_set)
const smaller_set : int_set = set_remove (3, my_set)
function update (var s : set (int)) : set (int) is block {
patch s with set [4; 7]
} with s
const new_set : set (int) = update (my_set)
function sum (const acc : int; const i : int): int is acc + i
const sum_of_elements : int = set_fold (sum, my_set, 0)
function loop (const s : set (int)) : int is block {
var sum : int := 0;
for element in set s block {
sum := sum + element
}
} with sum

16
gitlab-pages/docs/language-basics/src/sets-lists-tuples/sets.mligo Normal file
View File

@ -0,0 +1,16 @@
type int_set = int set
let my_set : int_set =
Set.add 3 (Set.add 2 (Set.add 2 (Set.add 1 (Set.empty : int set))))
let contains_3 : bool = Set.mem 3 my_set
let set_size : nat = Set.size my_set
let larger_set : int_set = Set.add 4 my_set
let smaller_set : int_set = Set.remove 3 my_set
let sum (acc, i : int * int) : int = acc + i
let sum_of_elements : int = Set.fold sum my_set 0

16
gitlab-pages/docs/language-basics/src/sets-lists-tuples/sets.religo Normal file
View File

@ -0,0 +1,16 @@
type int_set = set (int);
let my_set : int_set =
Set.add (3, Set.add (2, Set.add (2, Set.add (1, Set.empty : set (int)))));
let contains_3 : bool = Set.mem (3, my_set);
let set_size : nat = Set.size (my_set);
let larger_set : int_set = Set.add (4, my_set);
let smaller_set : int_set = Set.remove (3, my_set);
let sum = ((acc, i) : (int, int)) : int => acc + i;
let sum_of_elements : int = Set.fold (sum, my_set, 0);

1
gitlab-pages/docs/language-basics/src/strings/concat.ligo
View File

@ -1 +0,0 @@
const a: string = string_concat("Hello ", "World");

2
gitlab-pages/docs/language-basics/src/types/alias.ligo
View File

@ -1,2 +0,0 @@
type animalBreed is string;
const dogBreed : animalBreed = "Saluki";

4
gitlab-pages/docs/language-basics/src/types/annotation.ligo
View File

@ -1,4 +0,0 @@
type int_map is map(int, int);
function get_first(const int_map: int_map): option(int) is int_map[1]
// empty map needs a type annotation
const first: option(int) = get_first(((map end) : int_map ));

19
gitlab-pages/docs/language-basics/src/types/composed-types.ligo
View File

@ -1,19 +0,0 @@
// alias two types
type account is address;
type numberOfTransactions is nat;
// accountData consists of a record with two fields (balance, numberOfTransactions)
type accountData is record
balance: tez;
numberOfTransactions: numberOfTransactions;
end
// our ledger / accountBalances is a map of account <-> accountData
type accountBalances is map(account, accountData);
// pseudo-JSON representation of our map
// { "tz1...": {balance: 10mutez, numberOfTransactions: 5n} }
const ledger: accountBalances = map
("tz1KqTpEZ7Yob7QbPE4Hy4Wo8fHG8LhKxZSx": address) -> record
balance = 10mutez;
numberOfTransactions = 5n;
end
end

11
gitlab-pages/docs/language-basics/src/types/simple-type.ligo
View File

@ -1,6 +1,7 @@
// accountBalances is a simple type, a map of address <-> tez
type accountBalances is map(address, tez);
// The type accountBalances denotes maps from addresses to tez
const ledger: accountBalances = map
("tz1KqTpEZ7Yob7QbPE4Hy4Wo8fHG8LhKxZSx": address) -> 10mutez
end
type account_balances is map (address, tez)
const ledger : account_balances =
map
[("tz1KqTpEZ7Yob7QbPE4Hy4Wo8fHG8LhKxZSx" : address) -> 10mutez]

7
gitlab-pages/docs/language-basics/src/unit-option-pattern-matching/flip.ligo Normal file
View File

@ -0,0 +1,7 @@
type coin is Head | Tail
function flip (const c : coin) : coin is
case c of
Head -> Tail (Unit) // Unit needed because of a bug
| Tail -> Head (Unit) // Unit needed because of a bug
end

6
gitlab-pages/docs/language-basics/src/unit-option-pattern-matching/flip.mligo Normal file
View File

@ -0,0 +1,6 @@
type coin = Head | Tail
let flip (c : coin) : coin =
match c with
Head -> Tail
| Tail -> Head

7
gitlab-pages/docs/language-basics/src/unit-option-pattern-matching/flip.religo Normal file
View File

@ -0,0 +1,7 @@
type coin = | Head | Tail;
let flip = (c : coin) : coin =>
switch (c) {
| Head => Tail
| Tail => Head
};

11
gitlab-pages/docs/language-basics/src/variables-and-constants/add.ligo
View File

@ -1,7 +1,4 @@
// won't work, use const for global values instead
// var four: int = 4;
function add(const a: int; const b: int) : int is
block {
var c : int := a + b;
} with c
function add (const a : int; const b : int) : int is
block {
var c : int := a + b
} with c

2
gitlab-pages/docs/language-basics/src/variables-and-constants/add.mligo Normal file
View File

@ -0,0 +1,2 @@
let add (a : int) (b : int) : int =
let c : int = a + b in c

4
gitlab-pages/docs/language-basics/src/variables-and-constants/add.religo
View File

@ -1,4 +1,4 @@
let add = (a: int, b: int): int => {
let add = (a: int, b: int) : int => {
let c: int = a + b;
c;
};
};

1
gitlab-pages/docs/language-basics/src/variables-and-constants/const.mligo Normal file
View File

@ -0,0 +1 @@
let age : int = 25

75
gitlab-pages/docs/language-basics/strings.md
View File

@ -3,104 +3,97 @@ id: strings
title: Strings
---
Strings are defined using the built-in `string` type like this:
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
<!--PascaLIGO-->
```
const a: string = "Hello Alice";
const a : string = "Hello Alice"
```
<!--CameLIGO-->
```
let a: string = "Hello Alice"
let a : string = "Hello Alice"
```
<!--ReasonLIGO-->
```reasonligo
let a: string = "Hello Alice";
let a : string = "Hello Alice";
```
<!--END_DOCUSAURUS_CODE_TABS-->
## Concatenating strings
## Concatenating Strings
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
<!--PascaLIGO-->
Strings can be concatenated using the `^` operator.
```pascaligo
const name: string = "Alice";
const greeting: string = "Hello";
// Hello Alice
const full_greeting: string = greeting ^ " " ^ name;
// Hello Alice! (alternatively)
const full_greeting_exclamation: string = string_concat(full_greeting, "!");
const name : string = "Alice"
const greeting : string = "Hello"
const full_greeting : string = greeting ^ " " ^ name
```
<!--CameLIGO-->
Strings can be concatenated using the `^` operator.
```cameligo
let name: string = "Alice"
let greeting: string = "Hello"
let full_greeting: string = greeting ^ " " ^ name
let name : string = "Alice"
let greeting : string = "Hello"
let full_greeting : string = greeting ^ " " ^ name
```
<!--ReasonLIGO-->
Strings can be concatenated using the `++` operator.
```reasonligo
let name: string = "Alice";
let greeting: string = "Hello";
let full_greeting: string = greeting ++ " " ++ name;
let name : string = "Alice";
let greeting : string = "Hello";
let full_greeting : string = greeting ++ " " ++ name;
```
<!--END_DOCUSAURUS_CODE_TABS-->
## Slicing strings
## Slicing Strings
Strings can be sliced using the syntax specific built-in built-in function:
Strings can be sliced using a built-in function:
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
<!--PascaLIGO-->
```pascaligo
const name: string = "Alice";
// slice = "A"
const slice: string = string_slice(0n, 1n, name);
const name : string = "Alice"
const slice : string = string_slice (0n, 1n, name)
```
<!--CameLIGO-->
```cameligo
let name: string = "Alice"
let slice: string = String.slice 0n 1n name
let name : string = "Alice"
let slice : string = String.slice 0n 1n name
```
<!--ReasonLIGO-->
```reasonligo
let name: string = "Alice";
let slice: string = String.slice(0n, 1n, name);
let name : string = "Alice";
let slice : string = String.slice (0n, 1n, name);
```
<!--END_DOCUSAURUS_CODE_TABS-->
> ⚠️ Notice that the `offset` and slice `length` are `nats`
> ⚠️ Notice that the offset and length of the slice are natural numbers.
## Aquiring the length of a string
## Length of Strings
The length of a string can be found using the syntax specific built-in function:
The length of a string can be found using a built-in function:
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
<!--PascaLIGO-->
```pascaligo
const name: string = "Alice";
// length = 5
const length: nat = size(name);
const name : string = "Alice"
const length : nat = size (name) // length = 5
```
<!--CameLIGO-->
```cameligo
let name: string = "Alice"
let length: nat = String.size name
let name : string = "Alice"
let length : nat = String.size name // length = 5
```
<!--ReasonLIGO-->
```reasonligo
let name: string = "Alice";
let length: nat = String.size(name);
let name : string = "Alice";
let length : nat = String.size (name); // length == 5
```
<!--END_DOCUSAURUS_CODE_TABS-->

136
gitlab-pages/docs/language-basics/tezos-specific.md
View File

@ -3,38 +3,45 @@ id: tezos-specific
title: Tezos Domain-Specific Operations
---
LIGO is a language for writing Tezos smart contracts. It would be a little odd if
it didn't have any Tezos specific functions. This page will tell you about them.
LIGO is a programming language for writing Tezos smart contracts. It
would be a little odd if it did not have any Tezos specific
functions. This page will tell you about them.
## Pack and Unpack
Michelson provides the `PACK` and `UNPACK` instructions for data serialization.
`PACK` converts Michelson data structures to a binary format, and `UNPACK`
reverses it. This functionality can be accessed from within LIGO.
Michelson provides the `PACK` and `UNPACK` instructions for data
serialization. The instruction `PACK` converts Michelson data
structures into a binary format, and `UNPACK` reverses that
transformation. This functionality can be accessed from within LIGO.
> ⚠️ `PACK` and `UNPACK` are features of Michelson that are intended to be used by people that really know what they're doing. There are several failure cases (such as `UNPACK`ing a lambda from an untrusted source), most of which are beyond the scope of this document. Don't use these functions without doing your homework first.
> ⚠️ `PACK` and `UNPACK` are Michelson instructions that are intended
> to be used by people that really know what they are doing. There are
> several risks and failure cases, such as unpacking a lambda from an
> untrusted source, and most of which are beyond the scope of this
> document. Do not use these functions without doing your homework
> first.
<!--DOCUSAURUS_CODE_TABS-->
<!--PascaLIGO-->
```pascaligo
function id_string (const p : string) : option(string) is block {
const packed : bytes = bytes_pack(p) ;
} with (bytes_unpack(packed): option(string))
```pascaligo group=a
function id_string (const p : string) : option (string) is block {
const packed : bytes = bytes_pack (p)
} with (bytes_unpack (packed): option (string))
```
<!--CameLIGO-->
```cameligo
let id_string (p: string) : string option =
```cameligo group=a
let id_string (p : string) : string option =
let packed: bytes = Bytes.pack p in
((Bytes.unpack packed): string option)
(Bytes.unpack packed : string option)
```
<!--ReasonLIGO-->
```reasonligo
let id_string = (p: string) : option(string) => {
let packed : bytes = Bytes.pack(p);
((Bytes.unpack(packed)): option(string));
```reasonligo group=a
let id_string = (p : string) : option (string) => {
let packed : bytes = Bytes.pack (p);
(Bytes.unpack(packed) : option (string));
};
```
@ -42,41 +49,36 @@ let id_string = (p: string) : option(string) => {
## Hashing Keys
It's often desirable to hash a public key. In Michelson, certain data structures
such as maps will not allow the use of the `key` type. Even if this weren't the case
hashes are much smaller than keys, and storage on blockchains comes at a cost premium.
You can hash keys with the `key_hash` type and associated built in function.
It is often desirable to hash a public key. In Michelson, certain data
structures such as maps will not allow the use of the `key` type. Even
if this were not the case, hashes are much smaller than keys, and
storage on blockchains comes at a cost premium. You can hash keys with
a predefined functions returning a value of type `key_hash`.
<!--DOCUSAURUS_CODE_TABS-->
<!--PascaLIGO-->
```pascaligo
function check_hash_key (const kh1 : key_hash; const k2 : key) : bool * key_hash is block {
var ret : bool := False ;
var kh2 : key_hash := crypto_hash_key(k2) ;
if kh1 = kh2 then ret := True else skip;
} with (ret, kh2)
```pascaligo group=b
function check_hash_key (const kh1 : key_hash; const k2 : key) : bool * key_hash is
block {
var ret : bool := False;
var kh2 : key_hash := crypto_hash_key (k2);
if kh1 = kh2 then ret := True else skip
} with (ret, kh2)
```
<!--CameLIGO-->
```cameligo
let check_hash_key (kh1, k2: key_hash * key) : bool * key_hash =
```cameligo group=b
let check_hash_key (kh1, k2 : key_hash * key) : bool * key_hash =
let kh2 : key_hash = Crypto.hash_key k2 in
if kh1 = kh2
then (true, kh2)
else (false, kh2)
if kh1 = kh2 then true, kh2 else false, kh2
```
<!--ReasonLIGO-->
```reasonligo
let check_hash_key = ((kh1, k2): (key_hash, key)) : (bool, key_hash) => {
```reasonligo group=b
let check_hash_key = ((kh1, k2) : (key_hash, key)) : (bool, key_hash) => {
let kh2 : key_hash = Crypto.hash_key(k2);
if (kh1 == kh2) {
(true, kh2);
}
else {
(false, kh2);
}
if (kh1 == kh2) { (true, kh2); } else { (false, kh2); }
};
```
@ -84,60 +86,66 @@ let check_hash_key = ((kh1, k2): (key_hash, key)) : (bool, key_hash) => {
## Checking Signatures
Sometimes a contract will want to check that a message has been signed by a
particular key. For example, a point-of-sale system might want a customer to
sign a transaction so it can be processed asynchronously. You can do this in LIGO
using the `key` and `signature` types.
Sometimes a contract will want to check that a message has been signed
by a particular key. For example, a point-of-sale system might want a
customer to sign a transaction so it can be processed
asynchronously. You can do this in LIGO using the `key` and
`signature` types.
> ⚠️ There is no way to *generate* a signed message in LIGO. This is because that would require storing a private key on chain, at which point it isn't very private anymore.
> ⚠️ There is no way to *generate* a signed message in LIGO. This is
> because that would require storing a private key on chain, at which
> point it is not... private anymore.
<!--DOCUSAURUS_CODE_TABS-->
<!--PascaLIGO-->
```pascaligo
```pascaligo group=c
function check_signature
(const pk: key;
const signed: signature;
const msg: bytes) : bool
is crypto_check(pk, signed, msg)
(const pk : key;
const signed : signature;
const msg : bytes) : bool
is crypto_check (pk, signed, msg)
```
<!--CameLIGO-->
```cameligo
let check_signature (pk, signed, msg: key * signature * bytes) : bool =
```cameligo group=c
let check_signature (pk, signed, msg : key * signature * bytes) : bool =
Crypto.check pk signed msg
```
<!--ReasonLIGO-->
```reasonligo
let check_signature = ((pk, signed, msg): (key, signature, bytes)) : bool => {
Crypto.check(pk, signed, msg);
```reasonligo group=c
let check_signature =
((pk, signed, msg) : (key, signature, bytes)) : bool => {
Crypto.check (pk, signed, msg);
};
```
<!--END_DOCUSAURUS_CODE_TABS-->
## Getting The Contract's Own Address
Often you want to get the address of the contract being executed. You can do it with
`self_address`.
## Contract's Own Address
> ⚠️ Due to limitations in Michelson, self_address in a contract is only allowed at the entry-point level. Using it in a utility function will cause an error.
Often you want to get the address of the contract being executed. You
can do it with `self_address`.
> ⚠️ Due to limitations in Michelson, `self_address` in a contract is
> only allowed at the entrypoint level, that is, at the
> top-level. Using it in an embedded function will cause an error.
<!--DOCUSAURUS_CODE_TABS-->
<!--PascaLIGO-->
```pascaligo
const current_addr : address = self_address;
```pascaligo group=d
const current_addr : address = self_address
```
<!--CameLIGO-->
```cameligo
```cameligo group=d
let current_addr : address = Current.self_address
```
<!--ReasonLIGO-->
```reasonligo
```reasonligo group=d
let current_addr : address = Current.self_address;
```

294
gitlab-pages/docs/language-basics/types.md
View File

@ -3,163 +3,271 @@ id: types
title: Types
---
LIGO is strongly and statically typed. This means that the compiler checks your program at compilation time and makes sure there won't be any type related runtime errors. LIGO types are built on top of Michelson's type system.
*LIGO is strongly and statically typed.* This means that the compiler
checks how your contract processes data. If it passes the test, your
contract will not fail at run-time due to inconsistent assumptions on
your data. This is called *type checking*.
LIGO types are built on top of Michelson's type system.
## Built-in types
For quick referrence, you can find all the built-in types [here](https://gitlab.com/ligolang/ligo/blob/dev/src/passes/operators/operators.ml#L35).
For quick reference, you can find all the built-in types [here](https://gitlab.com/ligolang/ligo/blob/dev/src/passes/operators/operators.ml#L35).
## Type aliases
Type aliasing is great for creating a readable / maintainable smart contract. One well typed type/variable is worth a thousand words. For example we can choose to *alias* a string as an animal breed - this will allow us to comunicate our intent with added clarity.
*Type aliasing* consists in renaming a given type, when the context
calls for a more precise name. This increases readability and
maintainability of your smart contracts. For example we can choose to
alias a string type as an animal breed - this will allow us to
comunicate our intent with added clarity.
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
```pascaligo
type animalBreed is string;
const dogBreed : animalBreed = "Saluki";
<!--PascaLIGO-->
```pascaligo group=a
type breed is string
const dog_breed : breed = "Saluki"
```
<!--CameLIGO-->
```cameligo
type animal_breed = string
let dog_breed: animal_breed = "Saluki"
```cameligo group=a
type breed = string
let dog_breed : breed = "Saluki"
```
<!--ReasonLIGO-->
```reasonligo
type animal_breed = string;
let dog_breed: animal_breed = "Saluki";
```reasonligo group=a
type breed = string;
let dog_breed : breed = "Saluki";
```
<!--END_DOCUSAURUS_CODE_TABS-->
> Types in LIGO are `structural`, which means that `animalBreed`/`animal_breed` and `string` are interchangable and are considered equal.
> The above type definitions are aliases, which means that `breed` and
> `string` are interchangable in all contexts.
## Simple types
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
```pascaligo
// accountBalances is a simple type, a map of address <-> tez
type accountBalances is map(address, tez);
const ledger: accountBalances = map
("tz1KqTpEZ7Yob7QbPE4Hy4Wo8fHG8LhKxZSx": address) -> 10mutez
end
<!--DOCUSAURUS_CODE_TABS-->
<!--PascaLIGO-->
```pascaligo group=b
// The type accountBalances denotes maps from addresses to tez
type account_balances is map (address, tez)
const ledger : account_balances =
map [("tz1KqTpEZ7Yob7QbPE4Hy4Wo8fHG8LhKxZSx" : address) -> 10mutez]
```
<!--CameLIGO-->
```cameligo
// account_balances is a simple type, a map of address <-> tez
```cameligo group=b
// The type account_balances denotes maps from addresses to tez
type account_balances = (address, tez) map
let ledger: account_balances = Map.literal
[(("tz1KqTpEZ7Yob7QbPE4Hy4Wo8fHG8LhKxZSx": address), 10mutez)]
let ledger : account_balances =
Map.literal
[(("tz1KqTpEZ7Yob7QbPE4Hy4Wo8fHG8LhKxZSx" : address), 10mutez)]
```
<!--ReasonLIGO-->
```reasonligo
(* account_balances is a simple type, a map of address <-> tez *)
type account_balances = map(address, tez);
```reasonligo group=b
// The type account_balances denotes maps from addresses to tez
type account_balances = map (address, tez);
let ledger: account_balances =
Map.literal([
("tz1KqTpEZ7Yob7QbPE4Hy4Wo8fHG8LhKxZSx": address, 10mutez)
]);
Map.literal
([("tz1KqTpEZ7Yob7QbPE4Hy4Wo8fHG8LhKxZSx" : address, 10mutez)]);
```
<!--END_DOCUSAURUS_CODE_TABS-->
## Composed types
## Structured types
Often contracts require complex data structures, which in turn require well-typed storage or functions to work with. LIGO offers a simple way to compose simple types into larger & more expressive composed types.
Often contracts require complex data structures, which in turn require
well-typed storage or functions to work with. LIGO offers a simple way
to compose simple types into *structured types*.
In the example below you can see the definition of data types for a ledger that keeps the balance and number of previous transactions for a given account.
The first of those structured types is the *record*, which aggregates
types as *fields* and index them with a *field name*. In the example
below you can see the definition of data types for a ledger that keeps
the balance and number of previous transactions for a given account.
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
```pascaligo
// alias two types
type account is address;
type numberOfTransactions is nat;
// accountData consists of a record with two fields (balance, numberOfTransactions)
type accountData is record
balance: tez;
numberOfTransactions: numberOfTransactions;
end
// our ledger / accountBalances is a map of account <-> accountData
type accountBalances is map(account, accountData);
<!--PascaLIGO-->
```pascaligo group=c
// Type aliasing
// pseudo-JSON representation of our map
// { "tz1...": {balance: 10mutez, numberOfTransactions: 5n} }
const ledger: accountBalances = map
("tz1KqTpEZ7Yob7QbPE4Hy4Wo8fHG8LhKxZSx": address) -> record
balance = 10mutez;
numberOfTransactions = 5n;
end
end
type account is address
type number_of_transactions is nat
// The type account_data is a record with two fields.
type account_data is record [
balance : tez;
transactions : number_of_transactions
]
// A ledger is a map from accounts to account_data
type ledger is map (account, account_data)
const my_ledger : ledger = map [
("tz1KqTpEZ7Yob7QbPE4Hy4Wo8fHG8LhKxZSx" : address) ->
record [
balance = 10mutez;
transactions = 5n
]
]
```
<!--CameLIGO-->
```cameligo
(* alias two types *)
```cameligo group=c
// Type aliasing
type account = address
type number_of_transactions = nat
(* account_data consists of a record with two fields (balance, number_of_transactions) *)
type account_data = {
balance: tez;
number_of_transactions: number_of_transactions;
}
(* our ledger / account_balances is a map of account <-> account_data *)
type account_balances = (account, account_data) map
// pseudo-JSON representation of our map
// {"tz1...": {balance: 10mutez, number_of_transactions: 5n}}
let ledger: account_balances = Map.literal
[(("tz1KqTpEZ7Yob7QbPE4Hy4Wo8fHG8LhKxZSx": address),
{balance = 10mutez;
number_of_transactions = 5n;}
)]
// The type account_data is a record with two fields.
type account_data = {
balance : tez;
transactions : number_of_transactions
}
// A ledger is a map from accounts to account_data
type ledger = (account, account_data) map
let my_ledger : ledger = Map.literal
[(("tz1KqTpEZ7Yob7QbPE4Hy4Wo8fHG8LhKxZSx" : address),
{balance = 10mutez; transactions = 5n})]
```
<!--ReasonLIGO-->
```reasonligo
(* alias two types *)
```reasonligo group=c
// Type aliasing
type account = address;
type number_of_transactions = nat;
(* account_data consists of a record with two fields (balance, number_of_transactions) *)
// The type account_data is a record with two fields.
type account_data = {
balance: tez,
number_of_transactions,
balance : tez,
transactions : number_of_transactions
};
(* our ledger / account_balances is a map of account <-> account_data *)
type account_balances = map(account, account_data);
(* pseudo-JSON representation of our map
{"tz1...": {balance: 10mutez, number_of_transactions: 5n}} *)
let ledger: account_balances =
// A ledger is a map from accounts to account_data
type ledger = map (account, account_data);
let my_ledger : ledger =
Map.literal([
("tz1KqTpEZ7Yob7QbPE4Hy4Wo8fHG8LhKxZSx": address,
{balance: 10mutez, number_of_transactions: 5n})
]);
("tz1KqTpEZ7Yob7QbPE4Hy4Wo8fHG8LhKxZSx" : address,
{balance: 10mutez, transactions: 5n})]);
```
The structured types which are dual to records are the *variant types*
and they are described in the section about *pattern matching*. They
are dual because records are a product of types (types are bundled
into a record), whereas variant types are a sum of types (they are
exclusive to each other).
<!--END_DOCUSAURUS_CODE_TABS-->
## Annotations
In certain cases, type of an expression cannot be properly determined. This can be circumvented by annotating an expression with it's desired type, here's an example:
In certain cases, the type of an expression cannot be properly
inferred by the compiler. In order to help the type checker, you can
annotate an expression with its desired type. Here is an example:
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
```pascaligo
type int_map is map(int, int);
function get_first(const int_map: int_map): option(int) is int_map[1]
// empty map needs a type annotation
const first: option(int) = get_first(((map end) : int_map ));
<!--PascaLIGO-->
```pascaligo group=d
type parameter is Back | Claim | Withdraw
type storage is
record
owner : address;
goal : tez;
deadline : timestamp;
backers : map (address, tez);
funded : bool
end
type return is list (operation) * storage
function back (var action : unit; var store : storage) : return is
begin
if now > store.deadline then
failwith ("Deadline passed.")
else case store.backers[sender] of
None -> store.backers[sender] := amount
| Some (x) -> skip
end
end with ((nil : list (operation)), store) // Annotation
```
<!--END_DOCUSAURUS_CODE_TABS-->
<!--CameLIGO-->
```cameligo group=d
type parameter = Back | Claim | Withdraw
type storage = {
owner : address;
goal : tez;
deadline : timestamp;
backers : (address, tez) map;
funded : bool
}
type return = operation list * storage
let back (param, store : unit * storage) : return =
let no_op : operation list = [] in
if Current.time > store.deadline then
(failwith "Deadline passed." : return) // Annotation
else
match Map.find_opt sender store.backers with
None ->
let backers = Map.update sender (Some amount) store.backers
in no_op, {store with backers=backers}
| Some (x) -> no_op, store
```
<!--ReasonLIGO-->
```reasonligo group=d
type parameter = | Back | Claim | Withdraw;
type storage = {
owner : address,
goal : tez,
deadline : timestamp,
backers : map (address, tez),
funded : bool,
};
type return = (list (operation), storage);
let back = ((param, store) : (unit, storage)) : return => {
let no_op : list (operation) = [];
if (Current.time > store.deadline) {
(failwith ("Deadline passed.") : return); // Annotation
}
else {
switch (Map.find_opt (sender, store.backers)) {
| None => {
let backers = Map.update (sender, Some (amount), store.backers);
(no_op, {...store, backers:backers}) }
| Some (x) => (no_op, store)
}
}
};
```
<!--END_DOCUSAURUS_CODE_TABS-->

252
gitlab-pages/docs/language-basics/unit-option-pattern-matching.md
View File

@ -3,110 +3,156 @@ id: unit-option-pattern-matching
title: Unit, Option, Pattern matching
---
Optionals are a programing pattern seen in OCaml. Since Michelson and LIGO are both inspired by OCaml, you'll have the *option* to use them in LIGO as well.
Optionals are a pervasive programing pattern in OCaml. Since Michelson
and LIGO are both inspired by OCaml, *optional types* are available in
LIGO as well. Similarly, OCaml features a *unit* type, and LIGO
features it as well. Both the option type and the unit types are
instances of a more general kind of types: *variant types* (sometimes
called *sum types*).
## Type unit
## The unit Type
Units in Michelson or LIGO represent *for the lack of better words* - an empty/useless/not needed value.
Here's how they're defined:
> 💡 Units come in handy when we try pattern matching on custom variants below.
The `unit` type in Michelson or LIGO is a predefined type that
contains only one value that carries no information. It is used when
no relevant information is required or produced. Here is how it used.
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
```pascaligo
const n: unit = Unit;
<!--PascaLIGO-->
In PascaLIGO, the unique value of the `unit` type is `Unit`.
```pascaligo group=a
const n : unit = Unit // Note the capital letter
```
<!--CameLIGO-->
```cameligo
let n: unit = ()
In CameLIGO, the unique value of the `unit` type is `()`, following
the OCaml convention.
```cameligo group=a
let n : unit = ()
```
<!--ReasonLIGO-->
```reasonligo
let n: unit = ();
In ReasonLIGO, the unique value of the `unit` type is `()`, following
the OCaml convention.
```reasonligo group=a
let n : unit = ();
```
<!--END_DOCUSAURUS_CODE_TABS-->
## Variants
## Variant types
Variant is a user-defined or a built-in type (in case of optionals) that can be compared to Enum (from javascript).
A variant type is a user-defined or a built-in type (in case of
options) that defines a type by cases, so a value of a variant type is
either this, or that or... The simplest variant type is equivalent to
the enumerated types found in Java, C++, JavaScript etc.
Here's how to define a new variant type:
Here is how we define a coin as being either head or tail (and nothing
else):
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
```pascaligo
<!--PascaLIGO-->
```pascaligo group=b
type coin is Head | Tail
const head : coin = Head (Unit) // Unit needed for now.
const tail : coin = Tail (Unit) // Unit needed for now.
```
<!--CameLIGO-->
```cameligo group=b
type coin = Head | Tail
let head : coin = Head
let tail : coin = Tail
```
<!--ReasonLIGO-->
```reasonligo group=b
type coin = | Head | Tail;
let head : coin = Head;
let tail : coin = Tail;
```
<!--END_DOCUSAURUS_CODE_TABS-->
The names `Head` and `Tail` in the definition of the type `coin` are
called *data constructors*, or *variants*.
In general, it is interesting for variants to carry some information,
and thus go beyond enumerated types. In the following, we show how to
define different kinds of users of a system.
<!--DOCUSAURUS_CODE_TABS-->
<!--PascaLIGO-->
```pascaligo group=c
type id is nat
type user is
| Admin of id
Admin of id
| Manager of id
| Guest
const u : user = Admin (1000n)
const g : user = Guest (Unit) // Unit needed because of a bug
```
<!--CameLIGO-->
```cameligo group=c
type id = nat
type user =
Admin of id
| Manager of id
| Guest
let u : user = Admin 1000n
let g : user = Guest
```
<!--ReasonLIGO-->
```reasonligo group=c
type id = nat;
type user =
| Admin (id)
| Manager (id)
| Guest;
const u: user = Admin(1000n);
const g: user = Guest(Unit);
```
<!--CameLIGO-->
```cameligo
type id = nat
type user =
| Admin of id
| Manager of id
| Guest of unit
let u: user = Admin 1000n
let g: user = Guest ()
```
<!--ReasonLIGO-->
```reasonligo
type id = nat;
type user =
| Admin(id)
| Manager(id)
| Guest(unit);
let u: user = Admin(1000n);
let g: user = Guest();
let u : user = Admin (1000n);
let g : user = Guest;
```
<!--END_DOCUSAURUS_CODE_TABS-->
Defining a varient can be extremely useful for building semantically appealing contracts. We'll learn how to use variants for 'logic purposes' shortly.
## Optional values
Optionals are a type of built-in variant that can be used to determine if a variable holds a certain value or not. This is especially useful when (for example) your program's state allows for a certain variable value to be empty, like this:
The `option` type is a predefined variant type that is used to express
whether there is a value of some type or none. This is especially
useful when calling a *partial function*, that is, a function that is
not defined for some inputs. In that case, the value of the `option`
type would be `None`, otherwise `Some (v)`, where `v` is some
meaningful value *of any type*. An example in arithmetic is the
division operation:
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
```pascaligo
type dinner is option(string);
// stay hungry
const p1: dinner = None;
// have some hamburgers
const p2: dinner = Some("Hamburgers")
<!--PascaLIGO-->
```pascaligo group=d
function div (const a : nat; const b : nat) : option (nat) is
if b = 0n then (None: option (nat)) else Some (a/b)
```
<!--CameLIGO-->
```cameligo
type dinner = string option
let p1: dinner = None
let p2: dinner = Some "Hamburgers"
```cameligo group=d
let div (a, b : nat * nat) : nat option =
if b = 0n then (None: nat option) else Some (a/b)
```
<!--ReasonLIGO-->
```reasonligo
type dinner = option(string);
let p1: dinner = None;
let p2: dinner = Some("Hamburgers");
```reasonligo group=d
let div = ((a, b) : (nat, nat)) : option (nat) =>
if (b == 0n) { (None: option (nat)); } else { Some (a/b); };
```
<!--END_DOCUSAURUS_CODE_TABS-->
@ -114,38 +160,66 @@ let p2: dinner = Some("Hamburgers");
## Pattern matching
Pattern matching is very similiar to e.g. `switch` in Javascript, and can be used to re-route the program's flow based on a value of a variant.
*Pattern matching* is similiar to the `switch` construct in
Javascript, and can be used to route the program's control flow based
on the value of a variant. Consider for example the definition of a
function `flip` that flips a coin.
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
```pascaligo
type dinner is option(string);
function is_hungry(const dinner: dinner): bool is block { skip }
with (
case dinner of
| None -> True
| Some(d) -> False
end
)
<!--PascaLIGO-->
```pascaligo group=e
type coin is Head | Tail
function flip (const c : coin) : coin is
case c of
Head -> Tail (Unit) // Unit needed because of a bug
| Tail -> Head (Unit) // Unit needed because of a bug
end
```
You can call the function `flip` by using the LIGO compiler like so:
```shell
ligo run-function
gitlab-pages/docs/language-basics/src/unit-option-pattern-matching/flip.ligo
flip "(Head (Unit))"
# Outputs: Tail(Unit)
```
<!--CameLIGO-->
```cameligo
type dinner = string option
let is_hungry (d: dinner) : bool =
match d with
| None -> true
| Some s -> false
```cameligo group=e
type coin = Head | Tail
let flip (c : coin) : coin =
match c with
Head -> Tail
| Tail -> Head
```
You can call the function `flip` by using the LIGO compiler like so:
```shell
ligo run-function
gitlab-pages/docs/language-basics/src/unit-option-pattern-matching/flip.mligo
flip Head
# Outputs: Tail(Unit)
```
<!--ReasonLIGO-->
```reasonligo
type dinner = option(string);
let is_hungry = (d: dinner): bool =>
switch (d) {
| None => true
| Some(s) => false
```reasonligo group=e
type coin = | Head | Tail;
let flip = (c : coin) : coin =>
switch (c) {
| Head => Tail
| Tail => Head
};
```
You can call the function `flip` by using the LIGO compiler like so:
```shell
ligo run-function
gitlab-pages/docs/language-basics/src/unit-option-pattern-matching/flip.religo
flip Head
# Outputs: Tail(Unit)
```
<!--END_DOCUSAURUS_CODE_TABS-->

112
gitlab-pages/docs/language-basics/variables-and-constants.md
View File

@ -3,43 +3,48 @@ id: constants-and-variables
title: Constants & Variables
---
The next building block after types are constants and variables.
The next building block after types are *constants* and *variables*.
## Constants
Constants are immutable by design, which means their values can't be reassigned.
When defining a constant you need to provide a `name`, `type` and a `value`:
Constants are immutable by design, which means their values cannot be
reassigned. Put in another way, they can be assigned once, at their
declaration. When defining a constant you need to provide a `name`,
`type` and a `value`:
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
```pascaligo
const age : int = 25;
<!--PascaLIGO-->
```pascaligo group=a
const age : int = 25
```
You can evaluate the constant definition above using the following CLI command:
You can evaluate the constant definition above using the following CLI
command:
```shell
ligo evaluate-value -s pascaligo gitlab-pages/docs/language-basics/src/variables-and-constants/const.ligo age
ligo evaluate-value gitlab-pages/docs/language-basics/src/variables-and-constants/const.ligo age
# Outputs: 25
```
<!--CameLIGO-->
```cameligo
let age: int = 25
```cameligo group=a
let age : int = 25
```
You can evaluate the constant definition above using the following CLI command:
You can evaluate the constant definition above using the following CLI
command:
```shell
ligo evaluate-value -s cameligo gitlab-pages/docs/language-basics/src/variables-and-constants/const.mligo age
ligo evaluate-value gitlab-pages/docs/language-basics/src/variables-and-constants/const.mligo age
# Outputs: 25
```
<!--ReasonLIGO-->
```reasonligo
let age: int = 25;
```reasonligo group=a
let age : int = 25;
```
You can evaluate the constant definition above using the following CLI command:
You can evaluate the constant definition above using the following CLI
command:
```shell
ligo evaluate-value -s reasonligo gitlab-pages/docs/language-basics/src/variables-and-constants/const.religo age
ligo evaluate-value gitlab-pages/docs/language-basics/src/variables-and-constants/const.religo age
# Outputs: 25
```
@ -48,76 +53,71 @@ ligo evaluate-value -s reasonligo gitlab-pages/docs/language-basics/src/variable
## Variables
<!--DOCUSAURUS_CODE_TABS-->
<!--Pascaligo-->
<!--PascaLIGO-->
Variables, unlike constants, are mutable. They can't be used in a *global scope*, but they can be used within functions, or function arguments.
Variables, unlike constants, are *mutable*. They cannot be declared in
a *global scope*, but they can be declared and used within functions,
or as function parameters.
> 💡 Don't worry if you don't understand the function syntax yet. We'll get to it in upcoming sections of the docs.
> ⚠️ Please be wary that mutation only works within the function scope itself, values outside of the function scope will not be affected.
> ⚠️ Please be wary that mutation only works within the function scope
> itself, values outside of the function scope will not be affected.
```pascaligo group=b
// The following is invalid: use `const` for global values instead.
// var four : int := 4
```pascaligo
// won't work, use const for global values instead
// var four: int = 4;
function add(const a: int; const b: int) : int is
block {
var c : int := a + b;
} with c
function add (const a : int; const b : int) : int is
block {
var c : int := a + b
} with c
```
> ⚠️ Notice the assignment operator `:=` for `var`, instead of `=` for
> constants.
> ⚠️ Notice the different assignment operator `:=`
You can run the `add` function defined above using the LIGO compiler like this:
You can run the `add` function defined above using the LIGO compiler
like this:
```shell
ligo run-function -s pascaligo gitlab-pages/docs/language-basics/src/variables-and-constants/add.ligo add '(1,1)'
ligo run-function gitlab-pages/docs/language-basics/src/variables-and-constants/add.ligo add '(1,1)'
# Outputs: 2
```
<!--CameLIGO-->
As expected from a functional language, CameLIGO uses value-binding
for variables rather than assignment. Variables are changed by replacement,
with a new value being bound in place of the old one.
As expected in the pure subset of a functional language, CameLIGO only
features *constant values*: once they are declared, the value cannot
be changed (or "mutated").
> 💡 Don't worry if you don't understand the function syntax yet. We'll get to it in upcoming sections of the docs.
```cameligo
let add (a: int) (b: int) : int =
```cameligo group=c
let add (a : int) (b : int) : int =
let c : int = a + b in c
```
You can run the `add` function defined above using the LIGO compiler like this:
You can run the `add` function defined above using the LIGO compiler
like this:
```shell
ligo run-function -s cameligo gitlab-pages/docs/language-basics/src/variables-and-constants/add.mligo add '(1,1)'
ligo run-function gitlab-pages/docs/language-basics/src/variables-and-constants/add.mligo add '(1,1)'
# Outputs: 2
```
<!--ReasonLIGO-->
As expected from a functional language, ReasonLIGO uses value-binding
for variables rather than assignment. Variables are changed by replacement,
with a new value being bound in place of the old one.
As expected in the pure subset of a functional language, ReasonLIGO
only features *constant values*: once they are declared, the value
cannot be changed (or "mutated").
> 💡 Don't worry if you don't understand the function syntax yet. We'll get to it in upcoming sections of the docs.
```reasonligo
let add = ((a,b): (int, int)): int => {
let c: int = a + b;
```reasonligo group=c
let add = ((a, b): (int, int)): int => {
let c : int = a + b;
c;
};
```
You can run the `add` function defined above using the LIGO compiler like this:
You can run the `add` function defined above using the LIGO compiler
like this:
```shell
ligo run-function -s reasonligo gitlab-pages/docs/language-basics/src/variables-and-constants/add.religo add '(1,1)'
ligo run-function gitlab-pages/docs/language-basics/src/variables-and-constants/add.religo add '(1,1)'
# Outputs: 2
```

128
gitlab-pages/docs/reference/bytes.md Normal file
View File

@ -0,0 +1,128 @@
---
id: bytes-reference
title: Bytes
---
## Bytes.concat(b1: bytes, b2: bytes) : bytes
Concatenate together two `bytes` arguments and return the result.
<!--DOCUSAURUS_CODE_TABS-->
<!--PascaLIGO-->
```pascaligo
function concat_op (const s : bytes) : bytes is
begin skip end with bytes_concat(s , 0x7070)
```
<!--CameLIGO-->
```cameligo
let concat_op (s : bytes) : bytes =
Bytes.concat s 0x7070
```
<!--ReasonLIGO-->
```reasonligo
let concat_op = (s: bytes): bytes => Bytes.concat(s, 0x7070);
```
<!--END_DOCUSAURUS_CODE_TABS-->
## Bytes.slice(pos1: nat, pos2: nat, data: bytes) : bytes
Extract the bytes between `pos1` and `pos2`. **Positions are zero indexed and
inclusive**. For example if you gave the input "ff7a7aff" to the following:
<!--DOCUSAURUS_CODE_TABS-->
<!--PascaLIGO-->
```pascaligo
function slice_op (const s : bytes) : bytes is
begin skip end with bytes_slice(1n , 2n , s)
```
<!--CameLIGO-->
```cameligo
let slice_op (s : bytes) : bytes =
Bytes.slice 1n 2n s
```
<!--ReasonLIGO-->
```
let slice_op = (s: bytes): bytes => Bytes.slice(1n, 2n, s);
```
<!--END_DOCUSAURUS_CODE_TABS-->
It would return "7a7a" rather than "ff7a" or "ff" or "7a".
## Bytes.pack(data: a') : bytes
Converts Michelson data structures to a binary format for serialization.
> ⚠️ `PACK` and `UNPACK` are features of Michelson that are intended to be used by people that really know what they're doing. There are several failure cases (such as `UNPACK`ing a lambda from an untrusted source), most of which are beyond the scope of this document. Don't use these functions without doing your homework first.
<!--DOCUSAURUS_CODE_TABS-->
<!--PascaLIGO-->
```pascaligo
function id_string (const p : string) : option(string) is block {
const packed : bytes = bytes_pack(p) ;
} with (bytes_unpack(packed): option(string))
```
<!--CameLIGO-->
```cameligo
let id_string (p: string) : string option =
let packed: bytes = Bytes.pack p in
((Bytes.unpack packed): string option)
```
<!--ReasonLIGO-->
```reasonligo
let id_string = (p: string) : option(string) => {
let packed : bytes = Bytes.pack(p);
((Bytes.unpack(packed)): option(string));
};
```
<!--END_DOCUSAURUS_CODE_TABS-->
## Bytes.unpack(packed: bytes) : a'
Reverses the result of using `unpack` on data, going from Michelson's binary
serialization format to the `option` type annotated on the call.
> ⚠️ `PACK` and `UNPACK` are features of Michelson that are intended to be used by people that really know what they're doing. There are several failure cases (such as `UNPACK`ing a lambda from an untrusted source), most of which are beyond the scope of this document. Don't use these functions without doing your homework first.
<!--DOCUSAURUS_CODE_TABS-->
<!--PascaLIGO-->
```pascaligo
function id_string (const p : string) : option(string) is block {
const packed : bytes = bytes_pack(p) ;
} with (bytes_unpack(packed): option(string))
```
<!--CameLIGO-->
```cameligo
let id_string (p: string) : string option =
let packed: bytes = Bytes.pack p in
((Bytes.unpack packed): string option)
```
<!--ReasonLIGO-->
```reasonligo
let id_string = (p: string) : option(string) => {
let packed : bytes = Bytes.pack(p);
((Bytes.unpack(packed)): option(string));
};
```
<!--END_DOCUSAURUS_CODE_TABS-->

79
gitlab-pages/docs/reference/string.md Normal file
View File

@ -0,0 +1,79 @@
---
id: string-reference
title: String
---
## String.size(s: string) : nat
Get the size of a string. [Michelson only supports ASCII strings](http://tezos.gitlab.io/whitedoc/michelson.html#constants)
so for now you can assume that each character takes one byte of storage.
<!--DOCUSAURUS_CODE_TABS-->
<!--PascaLIGO-->
```pascaligo
function string_size (const s: string) : nat is size(s)
```
<!--CameLIGO-->
```cameligo
let size_op (s: string) : nat = String.size s
```
<!--ReasonLIGO-->
```reasonligo
let size_op = (s: string): nat => String.size(s);
```
<!--END_DOCUSAURUS_CODE_TABS-->
## String.length(s: string) : nat
Alias for `String.size`.
## String.slice(pos1: nat, pos2: nat, s: string) : string
Get the substring of `s` between `pos1` inclusive and `pos2` inclusive. For example
the string "tata" given to the function below would return "at".
<!--DOCUSAURUS_CODE_TABS-->
<!--PascaLIGO-->
```pascaligo
function slice_op (const s : string) : string is string_slice(1n , 2n , s)
```
<!--CameLIGO-->
```cameligo
let slice_op (s: string) : string = String.slice 1n 2n s
```
<!--ReasonLIGO-->
```reasonligo
let slice_op = (s: string): string => String.slice(1n, 2n, s);
```
<!--END_DOCUSAURUS_CODE_TABS-->
## String.sub(pos1: nat, pos2: nat, s: string) : string
Alias for `String.slice`.
## String.concat(s1: string, s2: string) : string
Concatenate two strings and return the result.
<!--DOCUSAURUS_CODE_TABS-->
<!--PascaLIGO-->
```pascaligo
function concat_op (const s : string) : string is s ^ "toto"
```
<!--CameLIGO-->
```cameligo
let concat_syntax (s: string) = s ^ "test_literal"
```
<!--ReasonLIGO-->
```reasonligo
let concat_syntax = (s: string) => s ++ "test_literal";
```
<!--END_DOCUSAURUS_CODE_TABS-->

12
gitlab-pages/docs/tutorials/get-started/tezos-taco-shop-smart-contract.md
View File

@ -1,13 +1,13 @@
---
id: tezos-taco-shop-smart-contract
title: Taco shop smart-contract
title: Taco shop smart contract
---
<div>
Meet **Pedro**, our *artisan taco chef* who has decided to open a Taco shop on the Tezos blockchain, using a smart-contract. He sells two different kinds of tacos, the **el clásico** and the **especial del chef**.
Meet **Pedro**, our *artisan taco chef* who has decided to open a Taco shop on the Tezos blockchain, using a smart contract. He sells two different kinds of tacos, the **el clásico** and the **especial del chef**.
To help Pedro open his dream taco shop, we'll implement a smart-contract, that will manage supply, pricing & sales of his tacos to the consumers.
To help Pedro open his dream taco shop, we'll implement a smart contract, that will manage supply, pricing & sales of his tacos to the consumers.
<br/>
<img src="/img/tutorials/get-started/tezos-taco-shop-smart-contract/taco-stand.svg" width="50%" />
@ -68,7 +68,7 @@ The best way to install the dockerized LIGO is as a **global executable** throug
> From now on we'll get a bit more technical. If you run into something we have not covered yet - please try checking out the [LIGO cheat sheet](api/cheat-sheet.md) for some extra tips & tricks.
To begin implementing our smart contract, we need an entry point. We'll call it `main` and it'll specify our contract's storage (`int`) and input parameter (`int`). Of course this is not the final storage/parameter of our contract, but it's something to get us started and test our LIGO installation as well.
To begin implementing our smart contract, we need an entry point. We'll call it `main` and it'll specify our contract's storage (`int`) and input parameter (`int`). Of course this is not the final storage/parameter of our contract, but it is something to get us started and test our LIGO installation as well.
### `taco-shop.ligo`
```pascaligo group=a
@ -138,7 +138,7 @@ end
type taco_shop_storage is map(nat, taco_supply);
```
Next step is to update the `main` entry point to include `taco_shop_storage` as its storage - while doing that let's set the `parameter` to `unit` as well to clear things up.
Next step is to update the `main` entry point to include `taco_shop_storage` in its storage - while doing that let's set the `parameter` to `unit` as well to clear things up.
**`taco-shop.ligo`**
```pascaligo group=b+
@ -154,7 +154,7 @@ function main (const parameter: unit ; const taco_shop_storage : taco_shop_stora
### Populating our storage in a dry-run
When dry-running a contract, it's crucial to provide a correct initial storage value - in our case the storage is type-checked as `taco_shop_storage`. Reflecting [Pedro's daily offer](tutorials/get-started/tezos-taco-shop-smart-contract.md#daily-offer), our storage's value will be defined as following:
When dry-running a contract, it is crucial to provide a correct initial storage value - in our case the storage is type-checked as `taco_shop_storage`. Reflecting [Pedro's daily offer](tutorials/get-started/tezos-taco-shop-smart-contract.md#daily-offer), our storage's value will be defined as following:
**Storage value**
```zsh

4
gitlab-pages/website/blog/2019-06-13-public-launch-of-ligo.md
View File

@ -8,7 +8,7 @@ author: Gabriel Alfour
---
## A Refresher: What is LIGO?
LIGO is a statically typed high-level smart-contract language that compiles down to Michelson. It seeks to be easy to use, extensible and safe.
LIGO is a statically typed high-level smart contract language that compiles down to Michelson. It seeks to be easy to use, extensible and safe.
The core language is being developed by The Marigold Project. George Dupéron and Christian Rinderknecht of Nomadic Labs help on the core language, and tooling for LIGO is being developed by Stove Labs (Granary, docs and infrastructure) and Brice Aldrich (syntax highlighting).
@ -95,7 +95,7 @@ We are looking to develop a Super Type System that has the following features:
The current version explicitly excludes non-essential features which can produce unexpected explosions in gas costs. To alleviate this constraint, we plan to integrate gas benchmarks on all top-level declarations with some fuzzing. This will allow developers and users to estimate the cost of their contracts in real time.
## Getting Started and Contact
Come visit [our website](https://ligolang.org)! You can also join our [Discord](https://discord.gg/9rhYaEt), Riot (*#ligo-public:matrix.org*) or Telegram Chat (Ligo Public channel).
Come visit [our website](https://ligolang.org)! You can also join our [Discord](https://discord.gg/9rhYaEt), Riot (*#ligo-public:matrix.org*) or [Telegram Chat](https://t.me/LigoLang).

6
gitlab-pages/website/blog/2019-07-11-ligo-update.md
View File

@ -7,7 +7,7 @@ author: Gabriel Alfour
---
It's been a few weeks since our last update. Since then, we've onboarded new collaborators to both LIGO and Marigold, rewritten much of the codebase, and we've begun some exciting new projects. Let's tell you all about it!
It has been a few weeks since our last update. Since then, we've onboarded new collaborators to both LIGO and Marigold, rewritten much of the codebase, and we've begun some exciting new projects. Let's tell you all about it!
# LIGO
@ -41,7 +41,7 @@ The most brittle part of our code base is about to become its strongest part. We
Concretely:
- Running LIGO-in-Browser will become much easier. Instead of having to dry-run it remotely or to rewrite a Michelson interpreter, we'll be able to **directly interpret** the LIGO program.
- It will be possible to prove the properties of Smart-Contracts written in LIGO directly, instead of having to prove the Michelson they produce.
- It will be possible to prove the properties of smart contracts written in LIGO directly, instead of having to prove the Michelson they produce.
- Fewer tests will ned to be written and testing will instead focus mostly on the developer-facing layers of the compiler (i.e. syntax, typing), rather than on the actual compiling part.
# Marigold
@ -56,4 +56,4 @@ It is thus hard for newcomers (even CS researchers!) to dive into Plasma in a co
# Contact
If you have any question, feel free to visit [our website](ligolang.org) and to contact us :)
If you have any question, feel free to visit [our website](https://ligolang.org) and to contact us :)

93
gitlab-pages/website/core/CodeExamples.js
View File

@ -3,68 +3,83 @@ const React = require('react');
const pre = '```';
const PASCALIGO_EXAMPLE = `${pre}pascaligo
// variant defining pseudo multi-entrypoint actions
type action is
| Increment of int
type storage is int
type parameter is
Increment of int
| Decrement of int
| Reset
function add (const a : int ; const b : int) : int is a + b
type return is list (operation) * storage
function subtract (const a : int ; const b : int) : int is a - b
// Two entrypoints
// real entrypoint that re-routes the flow based on the action provided
function main (const p : action ; const s : int) : (list(operation) * int) is
((nil : list(operation)),
case p of
| Increment (n) -> add (s, n)
| Decrement (n) -> subtract (s, n)
end)
function add (const store : storage; const delta : int) : storage is store + delta
function sub (const store : storage; const delta : int) : storage is store - delta
(* Main access point that dispatches to the entrypoints according to
the smart contract parameter. *)
function main (const action : parameter; const store : storage) : return is
((nil : list (operation)), // No operations
case action of
Increment (n) -> add (store, n)
| Decrement (n) -> sub (store, n)
| Reset -> 0
end)
${pre}`;
const CAMELIGO_EXAMPLE = `${pre}ocaml
type storage = int
(* variant defining pseudo multi-entrypoint actions *)
type action =
| Increment of int
type parameter =
Increment of int
| Decrement of int
| Reset
let add (a,b: int * int) : int = a + b
let sub (a,b: int * int) : int = a - b
type return = operation list * storage
(* real entrypoint that re-routes the flow based on the action provided *)
// Two entrypoints
let main (p,s: action * storage) =
let storage =
match p with
| Increment n -> add (s, n)
| Decrement n -> sub (s, n)
in ([] : operation list), storage
let add (store, delta : storage * int) : storage = store + delta
let sub (store, delta : storage * int) : storage = store - delta
(* Main access point that dispatches to the entrypoints according to
the smart contract parameter. *)
let main (action, store : parameter * storage) : return =
([] : operation list), // No operations
(match action with
Increment (n) -> add (store, n)
| Decrement (n) -> sub (store, n)
| Reset -> 0)
${pre}`;
const REASONLIGO_EXAMPLE = `${pre}reasonligo
type storage = int;
/* variant defining pseudo multi-entrypoint actions */
type parameter =
Increment (int)
| Decrement (int)
| Reset;
type action =
| Increment(int)
| Decrement(int);
type return = (list (operation), storage);
let add = ((a,b): (int, int)): int => a + b;
let sub = ((a,b): (int, int)): int => a - b;
(* Two entrypoints *)
/* real entrypoint that re-routes the flow based on the action provided */
let add = ((store, delta) : (storage, int)) : storage => store + delta;
let sub = ((store, delta) : (storage, int)) : storage => store - delta;
let main = ((p,storage): (action, storage)) => {
let storage =
switch (p) {
| Increment(n) => add((storage, n))
| Decrement(n) => sub((storage, n))
};
([]: list(operation), storage);
(* Main access point that dispatches to the entrypoints according to
the smart contract parameter. *)
let main = ((action, store) : (parameter, storage)) : return => {
(([] : list (operation)), // No operations
(switch (action) {
| Increment (n) => add ((store, n))
| Decrement (n) => sub ((store, n))
| Reset => 0}))
};
${pre}`;

4
gitlab-pages/website/pages/en/contact.js
View File

@ -47,8 +47,8 @@ const TEAM = [
const COMMUNICATION_CHANNELS = [
{
link: 'https://discord.gg/9rhYaEt',
icon: 'img/discord.svg',
link: 'https://t.me/LigoLang',
icon: 'img/telegram.svg',
description: "We're hear to help. Ask us anything"
},
{

8
gitlab-pages/website/pages/en/index.js
View File

@ -6,14 +6,14 @@ const docUrl = require(`${process.cwd()}/core/UrlUtils`).docUrl;
const FEATURES = [
{
image: 'img/strong-type-system.svg',
title: 'Strong Type System',
title: 'Strong, Static Type System',
content: 'Write types, then code. Benefit from the safety of type systems.'
},
{
image: 'img/syntax-agnostic.svg',
title: 'Syntax Agnostic',
title: 'Polyglot',
content:
'Code in your language. Write PascaLIGO, CameLIGO, or add your own syntax.'
'Code in your language. Write PascaLIGO, CameLIGO, ReasonLIGO or add your own syntax.'
},
{
image: 'img/easy-integration.svg',
@ -77,7 +77,7 @@ module.exports = props => {
</ul>
</div>
<div id="preview">
<h1>A friendly smart-contract language for Tezos</h1>
<h1>A friendly Smart Contract Language for Tezos</h1>
<p>Michelson was never so easy</p>
<CodeExamples MarkdownBlock={MarkdownBlock}></CodeExamples>
</div>

2
gitlab-pages/website/pages/en/versions.js
View File

@ -102,7 +102,7 @@ function Versions(props) {
</table>
<p>
You can find past versions of this project on{' '}
<a href={repoUrl}>Gitlab</a>.
<a href={repoUrl}>GitLab</a>.
</p>
</div>
</Container>

29
gitlab-pages/website/siteConfig.js
View File

@ -4,7 +4,7 @@ let reasonHighlightJs = require('reason-highlightjs');
const siteConfig = {
title: 'LIGO', // Title for your website.
tagline: 'LIGO is a friendly smart-contract language for Tezos',
tagline: 'LIGO is a friendly smart contract language for Tezos',
taglineSub: 'Michelson was never so easy',
url: 'https://ligolang.org', // Your website URL
baseUrl: '/', // Base URL for your project */
@ -14,7 +14,7 @@ const siteConfig = {
// Used for publishing and more
projectName: 'ligo',
organizationName: 'marigold',
organizationName: 'TBN',
// For top-level user or org sites, the organization is still the same.
// e.g., for the https://JoelMarcey.github.io site, it would be set like...
// organizationName: 'JoelMarcey'
@ -29,7 +29,7 @@ const siteConfig = {
label: 'Tutorials'
},
{ blog: true, label: 'Blog' },
// TODO: { href: "/odoc", label: "Api" },
// TODO: { href: "/odoc", label: "API" },
// { doc: 'contributors/origin', label: 'Contribute' },
{ href: '/contact', label: 'Ask Questions' },
{ search: true }
@ -40,14 +40,24 @@ const siteConfig = {
{ doc: 'intro/installation', label: 'Install' },
{ doc: 'api/cli-commands', label: 'CLI Commands' },
{ doc: 'contributors/origin', label: 'Contribute' },
{ href: '/odoc', label: 'Api Documentation' }
{ href: '/odoc', label: 'API Documentation' }
],
community: [
{
href: 'https://forum.tezosagora.org/tag/ligo',
label: 'Tezos Agora Forum',
blankTarget: true
},
{
href: 'https://tezos.stackexchange.com/questions/tagged/ligo',
label: 'Tezos Stack Exchange',
blankTarget: true
},
{
href: 'https://t.me/LigoLang',
label: 'Telegram',
blankTarget: true
},
{
href: 'https://discord.gg/9rhYaEt',
label: 'Discord',
@ -59,7 +69,7 @@ const siteConfig = {
doc: 'tutorials/get-started/tezos-taco-shop-smart-contract',
label: 'Tutorials'
},
{ href: repoUrl, label: 'Gitlab' }
{ href: repoUrl, label: 'GitLab' }
]
},
@ -87,10 +97,11 @@ const siteConfig = {
beginKeywords: '',
keywords: {
keyword:
'and begin block case const contains down else end fail for ' +
'from function if in is list map mod nil not of or patch ' +
'procedure record remove set skip step then to type var while with',
literal: 'true false unit int string some none bool nat list'
'and attributes begin big_map block case const contains else'
+ ' end False for from function if in is list map mod nil'
+ ' not of or patch record remove set skip then to True type'
+ ' var while with',
literal: 'true false unit int string Some None bool nat list'
},
lexemes: '[a-zA-Z][a-zA-Z0-9_]*',
contains: [

18
gitlab-pages/website/static/img/telegram.svg Normal file
View File

@ -0,0 +1,18 @@
<svg xmlns="http://www.w3.org/2000/svg" width="50" height="50" viewBox="0 0 50 50">
<defs>
<linearGradient id="telegram-a" x1="66.7%" x2="41.7%" y1="16.7%" y2="75%">
<stop offset="0%" stop-color="#37AEE2"/>
<stop offset="100%" stop-color="#1E96C8"/>
</linearGradient>
<linearGradient id="telegram-b" x1="66%" x2="85.1%" y1="43.065%" y2="83.244%">
<stop offset="0%" stop-color="#EFF7FC"/>
<stop offset="100%" stop-color="#FFF"/>
</linearGradient>
</defs>
<g fill="none" transform="translate(1 1)">
<circle cx="23.5" cy="23.5" r="23.5" fill="url(#telegram-a)"/>
<path fill="#C8DAEA" d="M19.2727273,35 C18.4774545,35 18.6126591,34.7064 18.3383636,33.966 L16,26.4414 L34,16"/>
<path fill="#A9C9DD" d="M19,35 C19.6818182,35 19.9829545,34.7309188 20.3636364,34.4116301 L24,31.3603439 L19.4640909,29"/>
<path fill="url(#telegram-b)" d="M19.7939067,28.5186178 L29.058792,35.7003368 C30.1161307,36.312398 30.8790086,35.9954126 31.1424333,34.6705866 L34.9137167,16.0247303 C35.2997536,14.4006073 34.3236454,13.6637218 33.3120947,14.1455316 L11.1671796,23.1045396 C9.65560092,23.7407214 9.66460526,24.6255468 10.8916853,25.0197183 L16.5745698,26.8808265 L29.7310517,18.1722711 C30.3521592,17.7770947 30.922306,17.9893563 30.4544638,18.4251358"/>
</g>
</svg>
Side by Side

After

Width:  |  Height:  |  Size: 1.3 KiB

12
gitlab-pages/website/versioned_docs/version-next/contributors/origin.md
View File

@ -4,8 +4,14 @@ title: Origin
original_id: origin
---
LIGO is a programming language that aims to provide developers with an uncomplicated and safer way to implement smart-contracts. LIGO is currently being implemented for the Tezos blockchain and as a result, it compiles down to Michelson - the native smart-contract language of Tezos.
LIGO is a programming language that aims to provide developers with an
uncomplicated and safe way to implement smart contracts. Since it is
being implemented for the Tezos blockchain LIGO compiles to Michelson,
the native smart contract language of Tezos.
> Smart-contracts are programs that run within a blockchain network.
> Smart contracts are programs that run within a blockchain network.
LIGO was initially meant to be a language for developing Marigold, on top of a hacky framework called Meta-Michelson. However, due to the attention received by the Tezos community, a decision has been put into action to develop LIGO as a standalone language that will support Tezos directly as well.
LIGO was meant to be a language for developing Marigold on top of a
hacky framework called Meta-Michelson. However, due to the attention
received by the Tezos community, LIGO is now a standalone language
being developed to support Tezos directly.

78
gitlab-pages/website/versioned_docs/version-next/contributors/philosophy.md
View File

@ -4,43 +4,79 @@ title: Philosophy
original_id: philosophy
---
To understand LIGO’s design choices, it’s important to get its philosophy. There are two main concerns that we have in mind when building LIGO.
To understand LIGO’s design choices it is important to understand its
philosophy. We have two main concerns in mind while building LIGO.
## Safety
Once a smart-contract is deployed, it will likely be impossible to change it. You must get it right on the first try, and LIGO should help as much as possible. There are multiple ways to make LIGO a safer language for smart-contracts.
Once a smart contract is deployed, it will likely be impossible to
change it. You must get it right on the first try, and LIGO should
help as much as possible. There are multiple ways to make LIGO a safer
language for smart contracts.
### Automated Testing
Automated Testing is the process through which a program will run some other program, and check that this other program behaves correctly.
There already is a testing library for LIGO programs written in OCaml that is used to test LIGO itself. Making it accessible to users will greatly improve safety. A way to do so would be to make it accessible from within LIGO.
Automated Testing is the process through which a program runs another
program, and checks that this other program behaves correctly.
There already is a testing library for LIGO programs written in OCaml
that is used to test LIGO itself. Making it accessible to users will
greatly improve safety. A way to do so would be to make it accessible
from within LIGO.
### Static Analysis
Static analysis is the process of having a program analyze another one.
For instance, type systems are a kind of static analysis through which it is possible to find lots of bugs. There is already a fairly simple type system in LIGO, and we plan to make it much stronger.
Static analysis is the process of having a program analyze another
one. For instance, type systems are a kind of static analysis through
which it is possible to find lots of bugs. LIGO already has a simple
type system, and we plan to make it much stronger.
### Conciseness
Writing less code gives you less room to introduce errors and that's why LIGO encourages writing lean rather than chunky smart-contracts.
Writing less code gives you less room to introduce errors. That is why
LIGO encourages writing lean rather than chunky smart contracts.
---
## Ergonomics
Having an ergonomic product is crucial on multiple levels:
Making features easily accessible ensures they’ll actually get used.
Not wasting users time on idiosyncrasies frees more time for making contracts safer or building apps.
Keeping users in a Flow state makes it possible to introduce more complex features in the language.
There are multiple ways to improve ergonomics.
Having an ergonomic product is crucial on multiple levels: Making
features easily accessible ensures they will actually get used. Not
wasting users time on idiosyncrasies frees more time for making
contracts safer or building apps. Keeping users in a Flow state makes
it possible to introduce more complex features in the language. There
are multiple ways to improve ergonomics.
### The Language
LIGO should contain as few surprises as possible. This is usually known as the principle of least surprise.
Most programmers who will use LIGO have already spent a lot of time learning to develop in an existing language, with its own set of conventions and expectations. These expectations are often the most important to accommodate. This is why C-style syntaxes are especially popular (e.g. JavaScript), C-style is well known and new languages want to take advantage of that familiarity. Therefore as an extension of the principle of least surprise, LIGO supports more than one syntax. The least surprising language for a new developer is the one that they have already learned how to use. It’s probably not practical to replicate the syntax of every programming language, so LIGO takes the approach of replicating the structure used by languages from a particular paradigm.
LIGO should contain as few surprises as possible. This is usually
known as the principle of least surprise.
It is packaged in a Docker container, so that no particular installation instructions are required.
Most programmers who will use LIGO have already spent a lot of time
learning to develop in an existing language, with its own set of
conventions and expectations. These expectations are often the most
important to accommodate. This is why C-style syntaxes are especially
popular (e.g. JavaScript), C-style is well known and new languages
want to take advantage of that familiarity. Therefore as an extension
of the principle of least surprise, LIGO supports more than one
syntax. The least surprising language for a new developer is the one
that they have already learned how to use. It’s probably not practical
to replicate the syntax of every programming language, so LIGO takes
the approach of replicating the structure used by languages from a
particular paradigm.
It is packaged in a Docker container, so that no particular
installation instructions are required.
### Editor Support
Without editor support, a lot of manipulations are very cumbersome. Checking for errors, testing, examining code, refactoring code, etc. This is why there is ongoing work on editor support, starting with highlighting and code-folding.
### Docs
Docs include documentation of the languages, tutorials, as well as examples and design patterns.
We’re a long way from there. But having extensive docs is part of our goals.
Without editor support, a lot of manipulations are very
cumbersome. Checking for errors, testing, examining code, refactoring
code, etc. This is why there is ongoing work on editor support,
starting with highlighting and code-folding.
### Documentation
Documentation includes a reference of the languages, tutorials, as
well as examples and design patterns. We are a long way from
there. But having an extensive documentation is part of our goals.

22
gitlab-pages/website/versioned_sidebars/version-next-sidebars.json
View File

@ -6,15 +6,27 @@
"version-next-intro/editor-support"
],
"Language Basics": [
"version-next-language-basics/cheat-sheet",
"version-next-language-basics/types",
"version-next-language-basics/variables",
"version-next-language-basics/constants-and-variables",
"version-next-language-basics/math-numbers-tez",
"version-next-language-basics/strings",
"version-next-language-basics/functions",
"version-next-language-basics/entrypoints",
"version-next-language-basics/operators"
"version-next-language-basics/boolean-if-else",
"version-next-language-basics/loops",
"version-next-language-basics/unit-option-pattern-matching",
"version-next-language-basics/maps-records",
"version-next-language-basics/sets-lists-tuples",
"version-next-language-basics/tezos-specific"
],
"Advanced": [
"version-next-advanced/timestamps-addresses",
"version-next-advanced/entrypoints-contracts",
"version-next-advanced/include",
"version-next-advanced/first-contract"
],
"API": [
"version-next-api-cli-commands"
"version-next-api/cli-commands",
"version-next-api/cheat-sheet"
]
},
"version-next-contributors-docs": {

3
scripts/build_docker_image.sh
View File

@ -1,3 +1,4 @@
#!/bin/sh
set -e
docker build -t "${LIGO_REGISTRY_IMAGE_BUILD:-ligolang/ligo}:next" -f ./docker/distribution/debian/distribute.Dockerfile .
set -x
docker build -t "${LIGO_REGISTRY_IMAGE_BUILD:-ligolang/ligo}:next" -f ./docker/distribution/debian/distribute.Dockerfile .

1
scripts/build_ligo_local.sh
View File

@ -1,5 +1,6 @@
#!/bin/sh
set -e
set -x
eval $(opam config env)
dune build -p ligo

2
scripts/distribution/generic/build.sh
View File

@ -1,4 +1,6 @@
#!/bin/sh
set -e
set -x
dockerfile_name="build"
# Generic dockerfile

2
scripts/distribution/generic/package.sh
View File

@ -1,4 +1,6 @@
#!/bin/sh
set -e
set -x
dockerfile_name="package"
dockerfile=""

14
scripts/distribution/generic/parameters.sh
View File

@ -1,11 +1,15 @@
# This script accepts three arguments, os family, os and it's version,
#!/bin/sh
set -e
set -x
# This script accepts three arguments, os family, os and its version,
# which are subsequently used to fetch the respective docker
# image from the ocaml/infrastructure project.
#
# https://github.com/ocaml/infrastructure/wiki/Containers#selecting-linux-distributions
target_os_family=$1
target_os=$2
target_os_version=$3
target_os_family="$1"
target_os="$2"
target_os_version="$3"
# Variables configured at the CI level
dist="$LIGO_DIST_DIR"
@ -29,4 +33,4 @@ fi
target_os_specific_dockerfile="./docker/distribution/$target_os_family/$target_os/$dockerfile_name.Dockerfile"
if test -f "$target_os_specific_dockerfile"; then
dockerfile="$target_os_specific_dockerfile"
fi
fi

Some files were not shown because too many files have changed in this diff Show More