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

Fixes after writing the slides.

Browse Source
This commit is contained in:
Christian Rinderknecht 2020-02-11 22:29:12 +01:00
parent 1cf90c8b38
commit 8c0a25bdb5
16 changed files with 309 additions and 291 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -18,9 +18,9 @@ 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.)
type of an access function 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-->
@ -45,9 +45,10 @@ type return = (list (operation), storage);
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.
modified by the access function. Instead, what it *does* mean is that,
given the state of the storage *on-chain*, an access function
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.
@ -57,28 +58,32 @@ is updated by the parameter.
<!--PascaLIGO-->
```pascaligo group=a
type parameter is nat
type storage is nat
type return is list (operation) * storage
function save (const parameter : nat; const store : storage) : return is
((nil : list (operation)), parameter)
function save (const action : parameter; const store : storage) : return is
((nil : list (operation)), store)
```
<!--CameLIGO-->
```cameligo group=a
type parameter = nat
type storage = nat
type return = operation list * storage
let save (parameter, store: nat * storage) : return =
(([] : operation list), parameter)
let save (action, store: parameter * storage) : return =
(([] : operation list), store)
```
<!--ReasonLIGO-->
```reasonligo group=a
type parameter = nat;
type storage = nat;
type return = (list (operation), storage);
let main = ((parameter, store): (nat, storage)) : return => {
(([] : list (operation)), parameter);
};
let main = ((action, store): (parameter, storage)) : return =>
(([] : list (operation)), store);
```
<!--END_DOCUSAURUS_CODE_TABS-->
@ -107,8 +112,8 @@ contract, either the counter or the name is updated.
<!--PascaLIGO-->
```pascaligo group=b
type parameter is
Entrypoint_A of nat
| Entrypoint_B of string
Action_A of nat
| Action_B of string
type storage is record [
counter : nat;
@ -117,24 +122,24 @@ type storage is record [
type return is list (operation) * storage
function handle_A (const n : nat; const store : storage) : return is
function entry_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
function entry_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)
function access (const action : parameter; const store : storage): return is
case action of
Action_A (n) -> entry_A (n, store)
| Action_B (s) -> entry_B (s, store)
end
```
<!--CameLIGO-->
```cameligo group=b
type parameter =
Entrypoint_A of nat
| Entrypoint_B of string
Action_A of nat
| Action_B of string
type storage = {
counter : nat;
@ -143,23 +148,23 @@ type storage = {
type return = operation list * storage
let handle_A (n, store : nat * storage) : return =
let entry_A (n, store : nat * storage) : return =
([] : operation list), {store with counter = n}
let handle_B (s, store : string * storage) : return =
let entry_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)
let access (action, store: parameter * storage) : return =
match action with
Action_A n -> entry_A (n, store)
| Action_B s -> entry_B (s, store)
```
<!--ReasonLIGO-->
```reasonligo group=b
type parameter =
| Entrypoint_A (nat)
| Entrypoint_B (string);
| Action_A (nat)
| Action_B (string);
type storage = {
counter : nat,
@ -168,18 +173,17 @@ type storage = {
type return = (list (operation), storage);
let handle_A = ((n, store): (nat, storage)) : return => {
(([] : list (operation)), {...store, counter : n}); };
let entry_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 entry_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))
}
};
let access = ((action, store): (parameter, storage)) : return =>
switch (action) {
| Action_A (n) => entry_A ((n, store))
| Action_B (s) => entry_B ((s, store))
};
```
<!--END_DOCUSAURUS_CODE_TABS-->
@ -203,7 +207,7 @@ type parameter is unit
type storage is unit
type return is list (operation) * storage
function deny (const param : parameter; const store : storage) : return is
function deny (const action : parameter; const store : storage) : return is
if amount > 0mutez then
(failwith ("This contract does not accept tokens.") : return)
else ((nil : list (operation)), store)
@ -215,7 +219,7 @@ type parameter = unit
type storage = unit
type return = operation list * storage
let deny (param, store : parameter * storage) : return =
let deny (action, store : parameter * storage) : return =
if amount > 0mutez then
(failwith "This contract does not accept tokens.": return)
else (([] : operation list), store)
@ -227,7 +231,7 @@ type parameter = unit;
type storage = unit;
type return = (list (operation), storage);
let deny = ((param, store): (parameter, storage)) : return => {
let deny = ((action, store): (parameter, storage)) : return => {
if (amount > 0mutez) {
(failwith("This contract does not accept tokens."): return); }
else { (([] : list (operation)), store); };
@ -245,7 +249,7 @@ This example shows how `sender` or `source` can be used to deny access to an ent
```pascaligo group=c
const owner : address = ("tz1KqTpEZ7Yob7QbPE4Hy4Wo8fHG8LhKxZSx": address);
function filter (const param : parameter; const store : storage) : return is
function filter (const action : parameter; const store : storage) : return is
if source =/= owner then (failwith ("Access denied.") : return)
else ((nil : list(operation)), store)
```
@ -254,7 +258,7 @@ function filter (const param : parameter; const store : storage) : return is
```cameligo group=c
let owner : address = ("tz1KqTpEZ7Yob7QbPE4Hy4Wo8fHG8LhKxZSx": address)
let filter (param, store: parameter * storage) : return =
let filter (action, store: parameter * storage) : return =
if source <> owner then (failwith "Access denied." : return)
else (([] : operation list), store)
```
@ -263,7 +267,7 @@ let filter (param, store: parameter * storage) : return =
```reasonligo group=c
let owner : address = ("tz1KqTpEZ7Yob7QbPE4Hy4Wo8fHG8LhKxZSx": address);
let main = ((param, store): (parameter, storage)) : storage => {
let access = ((action, store): (parameter, storage)) : storage => {
if (source != owner) { (failwith ("Access denied.") : return); }
else { (([] : list (operation)), store); };
};
@ -289,10 +293,10 @@ emiting a transaction operation at the end of an entrypoint.
> 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.
In our case, we have a `counter.ligo` contract that accepts an action
of type `parameter`, 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-->
@ -323,13 +327,13 @@ type return is list (operation) * storage
const dest : address = ("KT19wgxcuXG9VH4Af5Tpm1vqEKdaMFpznXT3" : address)
function proxy (const param : parameter; const store : storage): return is
function proxy (const action : 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 op : operation = transaction (action, 0mutez, counter);
const ops : list (operation) = list [op]
} with (ops, store)
```
@ -338,7 +342,7 @@ function proxy (const param : parameter; const store : storage): return is
```cameligo skip
// counter.mligo
type paramater =
type parameter =
Increment of nat
| Decrement of nat
| Reset
@ -360,12 +364,12 @@ type return = operation list * storage
let dest : address = ("KT19wgxcuXG9VH4Af5Tpm1vqEKdaMFpznXT3" : address)
let proxy (param, store : parameter * storage) : return =
let proxy (action, 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
let op : operation = Operation.transaction action 0mutez counter
in [op], store
```
@ -395,12 +399,12 @@ type return = (list (operation), storage);
let dest : address = ("KT19wgxcuXG9VH4Af5Tpm1vqEKdaMFpznXT3" : address);
let proxy = ((param, store): (parameter, storage)) : return => {
let proxy = ((action, 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);
let op : operation = Operation.transaction (action, 0mutez, counter);
([op], store)
};
```

16
gitlab-pages/docs/advanced/include.md
View File

@ -3,13 +3,12 @@ id: include
title: Including Other Contracts
---
Lets say we have a contract that's getting a bit too big. If it has a modular
structure, you might find it useful to use the `#include` statement to split the
contract up over multiple files.
Let us say that we have a contract that is getting a too large. If it
has a modular structure, you might find it useful to use the
`#include` statement to split the contract up over multiple files.
You take the code that you want to include and put it in a separate file, for
example `included.ligo`:
You take the code that you want to include and put it in a separate
file, for example `included.ligo`:
<!--DOCUSAURUS_CODE_TABS-->
@ -23,7 +22,6 @@ const foo : int = 144
<!--CameLIGO-->
```cameligo
// Demonstrate CameLIGO inclusion statements, see includer.mligo
let foo : int = 144
@ -31,7 +29,6 @@ let foo : int = 144
<!--ReasonLIGO-->
```reasonligo
// Demonstrate ReasonLIGO inclusion statements, see includer.religo
let foo : int = 144;
@ -46,7 +43,6 @@ And then you can include this code using the `#include` statement like so:
<!--PascaLIGO-->
```pascaligo
#include "included.ligo"
const bar : int = foo
@ -54,7 +50,6 @@ const bar : int = foo
<!--CameLIGO-->
```cameligo
#include "included.mligo"
let bar : int = foo
@ -62,7 +57,6 @@ let bar : int = foo
<!--ReasonLIGO-->
```reasonligo
#include "included.religo"
let bar : int = foo;

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

@ -33,10 +33,10 @@ let today : timestamp = Current.time;
<!--END_DOCUSAURUS_CODE_TABS-->
> When running code with ligo CLI, the option
> When running code, the LIGO CLI option
> `--predecessor-timestamp` allows you to control what `now` returns.
### Timestamp Arithmetic
### Timestamp Arithmetics
In LIGO, timestamps can be added to integers, allowing you to set time
constraints on your smart contracts. Consider the following scenarios.
@ -124,9 +124,9 @@ let not_tomorrow : bool = (Current.time == in_24_hrs);
## Addresses
The type `address` in LIGO denotes Tezos addresses (tz1, tz2, tz3,
The `address` type 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
`address` type. Beware of failures if the address is invalid. Consider
the following examples.
<!--DOCUSAURUS_CODE_TABS-->

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

@ -162,7 +162,7 @@ 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-->
```pascaligo group=a
type storage is int

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

@ -148,6 +148,29 @@ gitlab-pages/docs/language-basics/boolean-if-else/cond.ligo compare 21n'
# Outputs: Large (Unit)
```
When the branches of the conditional are not a single expression, as
above, we need a block:
```pascaligo skip
if x < y then
block {
const z : nat = x;
x := y; y := z
}
else skip;
```
As an exception to the rule, the blocks in a conditional branch do not
need to be introduced by the keywor `block`, so, we could have written
instead:
```pascaligo skip
if x < y then {
const z : nat = x;
x := y; y := z
}
else skip;
```
<!--CameLIGO-->
```cameligo group=e
type magnitude = Small | Large // See variant types.

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

@ -3,8 +3,8 @@ id: functions
title: Functions
---
LIGO features functions are the basic building block of contracts. For
example, entrypoints are functions.
LIGO functions are the basic building block of contracts. For example,
entrypoints are functions.
## Declaring Functions
@ -119,8 +119,8 @@ parameter, we should gather the arguments in a
[tuple](language-basics/sets-lists-tuples.md) and pass the tuple in as
a single parameter.
Here is how you define a basic function that accepts two `ints` and
returns an `int` as well:
Here is how you define a basic function that accepts two integers and
returns an integer as well:
```cameligo group=b
let add (a, b : int * int) : int = a + b // Uncurried
@ -137,10 +137,11 @@ ligo run-function gitlab-pages/docs/language-basics/src/functions/curry.mligo in
The function body is a single expression, whose value is returned.
<!--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.
<!--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
@ -154,7 +155,19 @@ ligo run-function gitlab-pages/docs/language-basics/src/functions/blockless.reli
# Outputs: 3
```
The function body is a single expression, whose value is returned.
As in CameLIGO and with blockless functions in PascaLIGO, the function
body is a single expression, whose value is returned.
If the body contains more than a single expression, you use block
between braces:
```reasonligo group=b
let myFun = ((x, y) : (int, int)) : int => {
let doubleX = x + x;
let doubleY = y + y;
doubleX + doubleY
};
```
<!--END_DOCUSAURUS_CODE_TABS-->
## Anonymous functions (a.k.a. lambdas)
@ -170,7 +183,6 @@ Here is how to define an anonymous function:
```pascaligo group=c
function increment (const b : int) : int is
(function (const a : int) : int is a + 1) (b)
const a : int = increment (1); // a = 2
```
@ -196,7 +208,7 @@ ligo evaluate-value gitlab-pages/docs/language-basics/src/functions/anon.mligo a
<!--ReasonLIGO-->
```reasonligo group=c
let increment = (b : int) : int => ((a : int) : int => a + 1)(b);
let increment = (b : int) : int => ((a : int) : int => a + 1) (b);
let a : int = increment (1); // a == 2
```
@ -257,5 +269,4 @@ gitlab-pages/docs/language-basics/src/functions/incr_map.religo incr_map
# Outputs: [ 2 ; 3 ; 4 ]
```
<!--END_DOCUSAURUS_CODE_TABS-->

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

@ -20,16 +20,15 @@ loops fails to become true, the execution will run out of gas and stop
with a failure anyway.
Here is how to compute the greatest common divisors of two natural
number by means of Euclid's algorithm:
numbers by means of Euclid's algorithm:
```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
}
if x < y then {
const z : nat = x;
x := y; y := z
}
else skip;
var r : nat := 0n;
while y =/= 0n block {
@ -55,18 +54,19 @@ 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.
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.
Instead, CameLIGO implements a *folded operation* by means of 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 *folded 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.
Here is how to compute the greatest common divisors of two natural
number by means of Euclid's algorithm:
numbers by means of Euclid's algorithm:
```cameligo group=a
let iter (x,y : nat * nat) : bool * (nat * nat) =
@ -117,7 +117,7 @@ accumulator is `t`, then it must have the type `bool * t` (not simply
condition has been reached.
Here is how to compute the greatest common divisors of two natural
number by means of Euclid's algorithm:
numbers by means of Euclid's algorithm:
```reasonligo group=a
let iter = ((x,y) : (nat, nat)) : (bool, (nat, nat)) =>
@ -149,11 +149,10 @@ let gcd = ((x,y) : (nat, nat)) : nat => {
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.
known as "for loops" and they have the form `for <variable assignment>
to <upper bound> <block>`, as found in imperative languages.
Consider how to sum integers from `0` to `n`:
Consider how to sum the natural numbers up to `n`:
```pascaligo group=c
function sum (var n : nat) : int is block {
@ -177,7 +176,7 @@ gitlab-pages/docs/language-basics/src/loops/sum.ligo sum 7n
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:
<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.
@ -202,7 +201,7 @@ gitlab-pages/docs/language-basics/src/loops/collection.ligo sum_list
Here is an example where the integers in a set are summed up.
```pascaligo=e
```pascaligo group=d
function sum_set (var s : set (int)) : int is block {
var total : int := 0;
for i in set s block {
@ -222,9 +221,23 @@ gitlab-pages/docs/language-basics/src/loops/collection.ligo sum_set
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
variables). Given a map from strings to integers, here is how to sum
all the integers and concatenate all the strings.
Here is an example where the keys are concatenated and the values are
summed up.
```pascaligo group=d
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)
```
You can call the function `sum_map` defined above using the LIGO compiler
like so:
```shell

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

@ -97,7 +97,7 @@ let alice_admin : bool = alice.is_admin
<!--ReasonLIGO-->
```reasonligo group=a
let alice_admin: bool = alice.is_admin;
let alice_admin : bool = alice.is_admin;
```
<!--END_DOCUSAURUS_CODE_TABS-->
@ -110,9 +110,7 @@ modified.
One way to understand the update of record values is the *functional
update*. The idea is to have an *expression* whose value is the
updated record. The shape of that expression is `<record variable>
with <record value>`. The record variable is the record to update and
the record value is the update itself.
updated record.
Let us consider defining a function that translates three-dimensional
points on a plane.
@ -120,6 +118,11 @@ points on a plane.
<!--DOCUSAURUS_CODE_TABS-->
<!--PascaLIGO-->
In PascaLIGO, the shape of that expression is `<record variable> with
<record value>`. The record variable is the record to update and the
record value is the update itself.
```pascaligo group=b
type point is record [x : int; y : int; z : int]
type vector is record [dx : int; dy : int]
@ -174,7 +177,7 @@ xy_translate "({x=2;y=3;z=1}, {dx=3;dy=4})"
<!--ReasonLIGO-->
The syntax for the functional updates of record in ReasonLIGO follows
that of OCaml:
that of ReasonML:
```reasonligo group=b
type point = {x : int, y : int, z : int};
@ -199,7 +202,7 @@ xy_translate "({x:2,y:3,z:1}, {dx:3,dy:4})"
You have to understand that `p` has not been changed by the functional
update: a nameless new version of it has been created and returned.
### Imperative Updates
### Record Patches
Another way to understand what it means to update a record value is to
make sure that any further reference to the value afterwards will
@ -365,12 +368,13 @@ let moves : register =
### Accessing Map Bindings
We can use the postfix `[]` operator to read the `move` value
associated to a given key (`address` here) in the register. Here is an
example:
<!--DOCUSAURUS_CODE_TABS-->
<!--PascaLIGO-->
In PascaLIGO, we can use the postfix `[]` operator to read the `move`
value associated to a given key (`address` here) in the register. Here
is an example:
```pascaligo group=f
const my_balance : option (move) =
moves [("tz1gjaF81ZRRvdzjobyfVNsAeSC6PScjfQwN" : address)]
@ -480,10 +484,9 @@ We can update a binding in a map in ReasonLIGO by means of the
`Map.update` built-in function:
```reasonligo group=f
let assign = (m : register) : register => {
let assign = (m : register) : register =>
Map.update
(("tz1gjaF81ZRRvdzjobyfVNsAeSC6PScjfQwN" : address), Some ((4,9)), m)
};
(("tz1gjaF81ZRRvdzjobyfVNsAeSC6PScjfQwN" : address), Some ((4,9)), m);
```
> Notice the optional value `Some (4,9)` instead of `(4,9)`. If we had
@ -521,9 +524,8 @@ let delete (key, moves : address * register) : register =
In ReasonLIGO, we use the predefined function `Map.remove` as follows:
```reasonligo group=f
let delete = ((key, moves) : (address, register)) : register => {
let delete = ((key, moves) : (address, register)) : register =>
Map.remove (key, moves);
};
```
<!--END_DOCUSAURUS_CODE_TABS-->
@ -540,7 +542,7 @@ 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
#### Iterated Operation over Maps
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
@ -595,7 +597,7 @@ let iter_op = (m : register) : unit => {
```
<!--END_DOCUSAURUS_CODE_TABS-->
#### Map Operation
#### Map Operations over Maps
We may want to change all the bindings of a map by applying to them a
function. This is called a *map operation*, not to be confused with
@ -606,7 +608,7 @@ the map data structure.
<!--PascaLIGO-->
In PascaLIGO, the predefined functional iterator implementing the map
operation over maps is called `map_map`and is used as follows:
operation over maps is called `map_map` and is used as follows:
```pascaligo group=f
function map_op (const m : register) : register is
@ -643,9 +645,9 @@ let map_op = (m : register) : register => {
```
<!--END_DOCUSAURUS_CODE_TABS-->
#### Fold Operation
#### Folded Operations over Maps
A *fold operation* is the most general of iterations. The folded
A *folded 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
@ -655,14 +657,15 @@ traversal of the data structure is over.
<!--PascaLIGO-->
In PascaLIGO, the predefined functional iterator implementing the fold
operation over maps is called `map_fold` and is used as follows:
In PascaLIGO, the predefined functional iterator implementing the
folded operation over maps is called `map_fold` and is used as
follows:
```pascaligo group=f
function fold_op (const m : register) : int is block {
function iterated (const j : int; const cur : address * move) : int is
function folded (const j : int; const cur : address * move) : int is
j + cur.1.1
} with map_fold (iterated, m, 5)
} with map_fold (folded, m, 5)
```
> The folded function must be pure, that is, it cannot mutate
@ -670,24 +673,26 @@ function fold_op (const m : register) : int is block {
<!--CameLIGO-->
In CameLIGO, the predefined functional iterator implementing the fold
operation over maps is called `Map.fold` and is used as follows:
In CameLIGO, the predefined functional iterator implementing the
folded operation over maps is called `Map.fold` and is used as
follows:
```cameligo group=f
let fold_op (m : register) : register =
let iterated = fun (i,j : int * (address * move)) -> i + j.1.1
in Map.fold iterated m 5
let folded = fun (i,j : int * (address * move)) -> i + j.1.1
in Map.fold folded m 5
```
<!--ReasonLIGO-->
In ReasonLIGO, the predefined functional iterator implementing the
fold operation over maps is called `Map.fold` and is used as follows:
folded operation over maps is called `Map.fold` and is used as
follows:
```reasonligo group=f
let fold_op = (m : register) : register => {
let iterated = ((i,j): (int, (address, move))) => i + j[1][1];
Map.fold (iterated, m, 5);
let folded = ((i,j): (int, (address, move))) => i + j[1][1];
Map.fold (folded, m, 5);
};
```

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

@ -60,13 +60,13 @@ let b : int = 5n + 10
let c : tez = 5mutez + 10mutez
// tez + int or tez + nat is invalid
// const d : tez = 5mutez + 10n
// let 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 f : nat = 5n + 10
let g : int = 1_000_000
```
@ -136,7 +136,7 @@ let a : int = 5 - 10
let b : int = 5n - 2n
// Therefore the following is invalid
// const c : nat = 5n - 2n
// let c : nat = 5n - 2n
let d : tez = 5mutez - 1mutez
```
@ -167,15 +167,17 @@ You can multiply values of the same type, such as:
```pascaligo group=c
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;
// You can also multiply `nat` and `tez`
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` in any order
// You can also multiply `nat` and `tez`
let c : tez = 5n * 5mutez
```
@ -183,7 +185,8 @@ let c : tez = 5n * 5mutez
```reasonligo group=c
let a : int = 5 * 5;
let b : nat = 5n * 5n;
// You can also multiply `nat` and `tez` in any order
// You can also multiply `nat` and `tez`
let c : tez = 5n * 5mutez;
```

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

@ -13,10 +13,10 @@ 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
is a *specific order*, so `(y,x)` is not equal to `(x,y)` in
general. 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: `(x,y)` has always a different type from
`(x,y,z)`, whereas `(y,x)` might have the same type as `(x,y)`.
Like records, tuple components can be of arbitrary types.
@ -68,10 +68,10 @@ position in their tuple, which cannot be done in OCaml.
<!--PascaLIGO-->
Tuple components are one-indexed like so:
Tuple components are one-indexed and accessed like so:
```pascaligo group=tuple
const first_name : string = full_name.1;
const first_name : string = full_name.1
```
<!--CameLIGO-->
@ -84,7 +84,7 @@ let first_name : string = full_name.0
<!--ReasonLIGO-->
Tuple components are one-indexed like so:
Tuple components are one-indexed and accessed like so:
```reasonligo group=tuple
let first_name : string = full_name[1];
@ -102,24 +102,27 @@ 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 needed when returning operations from a smart
> contract's access function.
### Defining Lists
<!--DOCUSAURUS_CODE_TABS-->
<!--PascaLIGO-->
```pascaligo group=lists
const empty_list : list (int) = nil // Or list []
const my_list : list (int) = list [1; 2; 2] // The head is 1
```
<!--CameLIGO-->
```cameligo group=lists
let empty_list : int list = []
let my_list : int list = [1; 2; 2] // The head is 1
```
<!--ReasonLIGO-->
```reasonligo group=lists
let empty_list : list (int) = [];
let my_list : list (int) = [1, 2, 2]; // The head is 1
```
@ -128,7 +131,6 @@ let my_list : list (int) = [1, 2, 2]; // The head is 1
### 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.
@ -167,12 +169,6 @@ let larger_list : list (int) = [5, ...my_list]; // [5,1,2,2]
```
<!--END_DOCUSAURUS_CODE_TABS-->
> 💡 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)
### Functional Iteration over Lists
A *functional iterator* is a function that traverses a data structure
@ -180,16 +176,23 @@ 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
There are three kinds of functional iterations over LIGO lists: the
*iterated operation*, the *map operation* (not to be confused with the
*map data structure*) and the *fold operation*.
#### Iterated Operation
> 💡 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)
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.
#### Iterated Operation over Lists
The first, the *iterated operation*, is an iteration over the list
with a unit return value. It is useful to enforce certain invariants
on the element of a list, or fail. For example you might want to check
that each value inside of a list is within a certain range, and fail
otherwise.
<!--DOCUSAURUS_CODE_TABS-->
@ -244,7 +247,7 @@ let iter_op = (l : list (int)) : unit => {
<!--END_DOCUSAURUS_CODE_TABS-->
#### Map Operation
#### Mapped Operation over Lists
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
@ -254,8 +257,9 @@ with the map data structure.
<!--PascaLIGO-->
In PascaLIGO, the predefined functional iterator implementing the map
operation over lists is called `list_map` and is used as follows:
In PascaLIGO, the predefined functional iterator implementing the
mapped operation over lists is called `list_map` and is used as
follows:
```pascaligo group=lists
function increment (const i : int): int is i + 1
@ -264,10 +268,14 @@ function increment (const i : int): int is i + 1
const plus_one : list (int) = list_map (increment, larger_list)
```
> The mapped function must be pure, that is, it cannot mutate
> variables.
<!--CameLIGO-->
In CameLIGO, the predefined functional iterator implementing the map
operation over lists is called `List.map` and is used as follows:
In CameLIGO, the predefined functional iterator implementing the
mapped operation over lists is called `List.map` and is used as
follows:
```cameligo group=lists
let increment (i : int) : int = i + 1
@ -278,8 +286,9 @@ let plus_one : int list = List.map increment larger_list
<!--ReasonLIGO-->
In ReasonLIGO, the predefined functional iterator implementing the map
operation over lists is called `List.map` and is used as follows:
In ReasonLIGO, the predefined functional iterator implementing the
mapped operation over lists is called `List.map` and is used as
follows:
```reasonligo group=lists
let increment = (i : int) : int => i + 1;
@ -290,9 +299,9 @@ let plus_one : list (int) = List.map (increment, larger_list);
<!--END_DOCUSAURUS_CODE_TABS-->
#### Fold Operation
#### Folded Operation over Lists
A *fold operation* is the most general of iterations. The folded
A *folded 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
@ -302,12 +311,12 @@ traversal of the data structure is over.
<!--PascaLIGO-->
In PascaLIGO, the predefined functional iterator implementing the fold
operation over lists is called `list_fold` and is used as follows:
In PascaLIGO, the predefined functional iterator implementing the
folded 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)
```
@ -316,7 +325,7 @@ const sum_of_elements : int = list_fold (sum, my_list, 0)
<!--CameLIGO-->
In CameLIGO, the predefined functional iterator implementing the fold
In CameLIGO, the predefined functional iterator implementing the folded
operation over lists is called `List.fold` and is used as follows:
```cameligo group=lists
@ -327,7 +336,8 @@ 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:
folded operation over lists is called `List.fold` and is used as
follows:
```reasonligo group=lists
let sum = ((result, i): (int, int)): int => result + i;
@ -365,7 +375,7 @@ let my_set : int set = Set.empty
<!--ReasonLIGO-->
In CameLIGO, the empty set is denoted by the predefined value
In ReasonLIGO, the empty set is denoted by the predefined value
`Set.empty`.
```reasonligo group=sets
@ -469,7 +479,7 @@ let contains_3 : bool = Set.mem (3, my_set);
<!--END_DOCUSAURUS_CODE_TABS-->
### Cardinal
### Cardinal of Sets
<!--DOCUSAURUS_CODE_TABS-->
@ -509,7 +519,7 @@ let set_size : nat = Set.size (my_set);
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
modify it in-place. First, let us consider the former way:
```pascaligo group=sets
const larger_set : set (int) = set_add (4, my_set)
@ -568,8 +578,8 @@ 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 *mapped operation* (not to be confused with
the *map data structure*) and the *folded operation*.
#### Iterated Operation
@ -631,18 +641,18 @@ let iter_op = (s : set (int)) : unit => {
<!--END_DOCUSAURUS_CODE_TABS-->
#### Map Operation
#### Mapped Operation (NOT IMPLEMENTED YET)
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.
them a function. This is called a *mapped 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:
In PascaLIGO, the predefined functional iterator implementing the
mapped operation over sets is called `set_map` and is used as follows:
```pascaligo skip
function increment (const i : int): int is i + 1
@ -653,8 +663,8 @@ 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:
In CameLIGO, the predefined functional iterator implementing the
mapped operation over sets is called `Set.map` and is used as follows:
```cameligo skip
let increment (i : int) : int = i + 1
@ -663,11 +673,10 @@ let increment (i : int) : int = i + 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:
In ReasonLIGO, the predefined functional iterator implementing the
mapped operation over sets is called `Set.map` and is used as follows:
```reasonligo skip
let increment = (i : int) : int => i + 1;
@ -678,9 +687,9 @@ let plus_one : set (int) = Set.map (increment, larger_set);
<!--END_DOCUSAURUS_CODE_TABS-->
#### Fold Operation
#### Folded Operation
A *fold operation* is the most general of iterations. The folded
A *folded 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
@ -690,8 +699,9 @@ traversal of the data structure is over.
<!--PascaLIGO-->
In PascaLIGO, the predefined functional iterator implementing the fold
operation over sets is called `set_fold` and is used as follows:
In PascaLIGO, the predefined functional iterator implementing the
folded 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

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

@ -27,7 +27,7 @@ let a : string = "Hello Alice";
<!--PascaLIGO-->
Strings can be concatenated using the `^` operator.
```pascaligo
```pascaligo group=a
const name : string = "Alice"
const greeting : string = "Hello"
const full_greeting : string = greeting ^ " " ^ name
@ -35,7 +35,7 @@ const full_greeting : string = greeting ^ " " ^ name
<!--CameLIGO-->
Strings can be concatenated using the `^` operator.
```cameligo
```cameligo group=a
let name : string = "Alice"
let greeting : string = "Hello"
let full_greeting : string = greeting ^ " " ^ name
@ -43,7 +43,7 @@ let full_greeting : string = greeting ^ " " ^ name
<!--ReasonLIGO-->
Strings can be concatenated using the `++` operator.
```reasonligo
```reasonligo group=a
let name : string = "Alice";
let greeting : string = "Hello";
let full_greeting : string = greeting ++ " " ++ name;
@ -57,17 +57,17 @@ Strings can be sliced using a built-in function:
<!--DOCUSAURUS_CODE_TABS-->
<!--PascaLIGO-->
```pascaligo
```pascaligo group=b
const name : string = "Alice"
const slice : string = string_slice (0n, 1n, name)
```
<!--CameLIGO-->
```cameligo
```cameligo group=b
let name : string = "Alice"
let slice : string = String.slice 0n 1n name
```
<!--ReasonLIGO-->
```reasonligo
```reasonligo group=b
let name : string = "Alice";
let slice : string = String.slice (0n, 1n, name);
```
@ -81,18 +81,18 @@ The length of a string can be found using a built-in function:
<!--DOCUSAURUS_CODE_TABS-->
<!--PascaLIGO-->
```pascaligo
```pascaligo group=c
const name : string = "Alice"
const length : nat = size (name) // length = 5
```
<!--CameLIGO-->
```cameligo
```cameligo group=c
let name : string = "Alice"
let length : nat = String.size name // length = 5
```
<!--ReasonLIGO-->
```reasonligo
```reasonligo group=c
let name : string = "Alice";
let length : nat = String.size (name); // length == 5
```

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

@ -10,16 +10,15 @@ functions. This page will tell you about them.
## Pack and Unpack
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.
serialization. The former converts Michelson data structures into a
binary format, and the latter reverses that transformation. This
functionality can be accessed from within LIGO.
> ⚠️ `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.
> untrusted source or casting the result to the wrong type. Do not use
> the corresponding LIGO functions without doing your homework first.
<!--DOCUSAURUS_CODE_TABS-->
@ -27,7 +26,7 @@ transformation. This functionality can be accessed from within LIGO.
```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))
} with (bytes_unpack (packed) : option (string))
```
<!--CameLIGO-->
@ -77,7 +76,7 @@ let check_hash_key (kh1, k2 : key_hash * key) : bool * key_hash =
<!--ReasonLIGO-->
```reasonligo group=b
let check_hash_key = ((kh1, k2) : (key_hash, key)) : (bool, key_hash) => {
let kh2 : key_hash = Crypto.hash_key(k2);
let kh2 : key_hash = Crypto.hash_key (k2);
if (kh1 == kh2) { (true, kh2); } else { (false, kh2); }
};
```
@ -116,9 +115,8 @@ let check_signature (pk, signed, msg : key * signature * bytes) : bool =
<!--ReasonLIGO-->
```reasonligo group=c
let check_signature =
((pk, signed, msg) : (key, signature, bytes)) : bool => {
((pk, signed, msg) : (key, signature, bytes)) : bool =>
Crypto.check (pk, signed, msg);
};
```
<!--END_DOCUSAURUS_CODE_TABS-->
@ -129,8 +127,8 @@ 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.
> only allowed at the top-level. Using it in an embedded function will
> cause an error.
<!--DOCUSAURUS_CODE_TABS-->

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

@ -53,13 +53,12 @@ let dog_breed : breed = "Saluki";
<!--DOCUSAURUS_CODE_TABS-->
<!--PascaLIGO-->
```pascaligo group=b
// The type accountBalances denotes maps from addresses to tez
// The type account_balances denotes maps from addresses to tez
type account_balances is map (address, tez)
const ledger : account_balances =
map [("tz1KqTpEZ7Yob7QbPE4Hy4Wo8fHG8LhKxZSx" : address) -> 10mutez]
```
<!--CameLIGO-->

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

@ -69,7 +69,8 @@ or as function parameters.
function add (const a : int; const b : int) : int is
block {
var c : int := a + b
var c : int := a + 2*b;
c := c - b
} with c
```

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

@ -4,14 +4,8 @@ title: Origin
original_id: 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.
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.
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.

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

@ -4,79 +4,42 @@ title: Philosophy
original_id: philosophy
---
To understand LIGO’s design choices it is important to understand its
philosophy. We have two main concerns in mind while building LIGO.
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.
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.
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. LIGO already has a simple
type system, 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. That is 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.
---
## 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.
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.
### The Language
LIGO should contain as few surprises as possible. This is usually known as the principle of least surprise.
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.
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.
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.
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.
### 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.