11 |
13 | 14 | This book, currently in its alpha version, is dedicated to Aqua, with plans to significantly broaden its scope in the future. 15 | -------------------------------------------------------------------------------- /docs/aqua-book/language/abilities.md: -------------------------------------------------------------------------------- 1 | # Abilities 2 | 3 | Abilities are a way to organize code in modules and implement inversion of control pattern in Aqua. 4 | 5 | 6 | Ability is a product of [scalars](types.md#scalars), [structures](types.md#structures), [arrows](types.md#arrow-types) and other abilities. 7 | 8 | ```aqua 9 | data Struct: 10 | int: i8 11 | 12 | ability Simple: 13 | st: Struct 14 | arrow(x: i8) -> bool 15 | 16 | ability Complex: 17 | simple: Simple 18 | field: string 19 | ``` 20 | 21 | ## Creating abilities 22 | 23 | Abilities could be created inside functions just like [structures](types.md#structures). 24 | 25 | 26 | ```aqua 27 | func main(): 28 | closure = (x: i8) -> bool: 29 | <- x > 0 30 | 31 | field = "complex" 32 | 33 | MyComplex = Complex( 34 | simple = Simple( 35 | st = Struct(int = 0), 36 | arrow = closure 37 | ), 38 | field -- short for `field = field` 39 | ) 40 | ``` 41 | 42 | ## Passing abilities 43 | 44 | Abilities could be passed to and returned from functions, althrough they require special syntax: 45 | - Abilities required by function are listed before arguments without names 46 | - Abilities returned by function are listed in return types just as any other types 47 | 48 | ```aqua 49 | ability Additional: 50 | value: string 51 | 52 | func createComplex{Simple, Additional}(int: i8) -> Complex, string: 53 | MyComplex = Complex( 54 | simple = Simple( 55 | st = Struct(int = int), 56 | arrow = Simple.arrow 57 | ), 58 | field = Additional.value 59 | ) 60 | 61 | <- MyComplex, Additional.value 62 | 63 | func main() -> string, string: 64 | closure = (x: i8) -> bool: 65 | <- x > 0 66 | 67 | MySimple = Simple( 68 | st = Struct(int = 0), 69 | arrow = closure 70 | ) 71 | 72 | MyAdditional = Additional(value = "additional") 73 | 74 | MyComplex, value = createComplex{MySimple, MyAdditional}(42) 75 | 76 | <- MyComples.field, value 77 | ``` 78 | 79 | 80 | 81 | ## Why abilities are special 82 | 83 | Abilities are fully resolved in compile time and do not affect runtime by any means. 84 | In this sense they are more like a context or trait implementation in other languages. 85 | For this reason special syntax is used. 86 | 87 | ## Limitations 88 | 89 | As abilities do not exist in runtime, they could not be put into a [collection](types.md#collection-types). -------------------------------------------------------------------------------- /docs/aqua-book/language/closures.md: -------------------------------------------------------------------------------- 1 | # Closures 2 | 3 | In Aqua, you can create an arrow within the function, enclosing its context. 4 | 5 | ```aqua 6 | service Hello: 7 | say_hello(to_name: string, peer: string) 8 | 9 | func bar(callback: string -> ()): 10 | callback("Fish") 11 | 12 | func foo(peer: string): 13 | on peer: 14 | -- Capture service resolution 15 | Hello "world" 16 | -- Create a closure named "closure" 17 | closure = (name: string) -> string: 18 | -- Use a value that's available on the definition site 19 | -- To call a service that's resolved on the definition site 20 | Hello.say_hello(name, peer) 21 | -- Return a value from the closure; syntax is the same as in functions 22 | <- name 23 | -- Pass this closure to another function 24 | bar(closure) 25 | ``` 26 | 27 | Closures can be created anywhere in the function, starting with Aqua 0.4.1, and then used just like any other arrow (argument of arrow type, function, or service method): passed to another function as an argument, or called right there. 28 | 29 | Closures enclose over three domains: 30 | 31 | * Values in scope, 32 | * Service resolutions, 33 | * Topology: place where the closure is defined should be the place where it's executed. 34 | 35 | Comparing with functions, closures have one important difference: functions are detached from topology by default. `func` keyword can be used to bring this behavior to closures, if needed. 36 | 37 | ```aqua 38 | service Hello: 39 | say_hello() 40 | 41 | func foo(): 42 | on HOST_PEER_ID: 43 | Hello "hello" 44 | 45 | -- This closure will execute on HOST_PEER_ID 46 | closure = (): 47 | Hello.say_hello() 48 | 49 | fn = func (): 50 | Hello.say_hello() 51 | 52 | -- Will go to HOST_PEER_ID, where Hello service is resolved, and call say_hello 53 | closure() 54 | 55 | -- Will be called on current peer, probably INIT_PEER_ID, and may fail 56 | -- in case Hello service is not defined or has another ID 57 | fn() 58 | ``` 59 | 60 | It is not yet possible to return an arrow from an arrow. 61 | -------------------------------------------------------------------------------- /docs/aqua-book/language/crdt-streams.md: -------------------------------------------------------------------------------- 1 | # CRDT Streams 2 | 3 | In Aqua, an ordinary value is a name that points to a single result: 4 | 5 | ```aqua 6 | value <- foo() 7 | ``` 8 | 9 | A stream, on the other hand, is a name that points to zero or more results: 10 | 11 | ```aqua 12 | values: *string 13 | 14 | -- Write to a stream several times 15 | values <- foo() 16 | values <- foo() 17 | 18 | -- A value can be pushed to a stream 19 | -- without an explicit function call with <<- operator: 20 | values <<- "foo" 21 | x <- foo() 22 | values <<- x 23 | ``` 24 | 25 | Stream is a kind of [collection](types.md#collection-types) and can be used in place of other collections: 26 | 27 | ```aqua 28 | func foo(peer: string, relay: ?string): 29 | on peer via relay: 30 | Op.noop() 31 | 32 | func bar(peer: string, relay: string): 33 | relayMaybe: *string 34 | if peer != INIT_PEER_ID: 35 | -- Write into a stream 36 | relayMaybe <<- relay 37 | -- Pass a stream as an optional value 38 | foo(peer, relayMaybe) 39 | ``` 40 | 41 | But the most powerful use of streams pertains to their use with parallel execution, which incurs non-determinism. 42 | 43 | ## Streams: Lifecycle And Guarantees 44 | 45 | A stream's lifecycle can be separated into three stages: 46 | 47 | * Source: (Parallel) Writes to a stream 48 | * Map: Handles the stream values 49 | * Sink: Converts the resulting stream into a scalar 50 | 51 | Consider the following example: 52 | 53 | ```aqua 54 | alias PeerId: string 55 | 56 | func foo(peers: []PeerId) -> string: 57 | -- Store a list of peer IDs collected from somewhere 58 | -- This is a stream (denoted by *, which means "0 or more values") 59 | resp: *PeerId 60 | 61 | -- Will go to all peers in parallel 62 | for p <- peers par: 63 | -- Move execution flow to the peer p 64 | on p: 65 | -- Get a peer ID from a service call (called on p) 66 | resp <- Srv.call() 67 | 68 | -- You can think of resp2 as a locally consistent lazy list 69 | resp2: *PeerId 70 | 71 | -- What is the value of resp at this point? 72 | -- Keep an eye on the `par` there: actually, it's FORKing execution 73 | -- to several branches on different peers. 74 | for r <- resp par: 75 | -- Move execution to peer r 76 | on r: 77 | -- Call Srv locally 78 | resp2 <- Srv.call() 79 | 80 | -- Wait for 6 responses on resp2: it's JOIN 81 | Op.identity(resp2!5) 82 | -- Once we have 6 responses, merge them 83 | -- Function treats resp2 as an array of strings, and concatenates all 84 | -- of them into a single string. 85 | -- This function call "fixes" the content of resp2, making a single observation. 86 | -- This is a "stream canonicalization" event: values, order, and length 87 | -- is fixed at the moment of first function call, function will not be called 88 | -- again, with different data. 89 | r <- Srv.concat(resp2) 90 | -- You can keep writing to a stream after it's value is used 91 | 92 | <- r 93 | ``` 94 | 95 | In this case, for each peer `p` in `peers`, a new `PeerID` is going to be obtained from the `Srv.call` and written into the `resp` stream. 96 | 97 | Every peer `p` in peers does not know anything about how the other iterations proceed. 98 | 99 | Once `PeerId` is written to the `resp` stream, the second `for` is triggered. This is the mapping stage. 100 | 101 | And then the results are sent to the first peer, to call Op.identity there. This Op.identity waits until element number 5 is defined on `resp2` stream. 102 | 103 | When the join is complete, the stream is consumed by the concatenation service to produce a scalar value, which is returned. 104 | 105 | During execution, involved peers have different views on the state of execution: each of the `for` parallel branches has no view or access to the other branches' data and eventually, the execution flows to the initial peer. The initial peer then merges writes to the `resp` stream and to the `resp2` stream, respectively. These writes are done in a conflict-free fashion. Furthermore, the respective heads of the `resp`, `resp2` streams will not change from each peer's point of view as they are immutable and new values can only be appended. However, different peers may have a different order of the stream values depending on the order of receiving these values. 106 | 107 | ### Stream restrictions 108 | 109 | Restriction is a part of π calculus that bounds (restricts) a name to a scope. For Aqua streams it means that the stream is not accessible outside of definition scope, and the stream is always fresh when execution enters the scope. 110 | 111 | These behaviors are introduced in [Aqua 0.5](https://github.com/fluencelabs/aqua/releases/tag/0.5.0). 112 | 113 | ```aqua 114 | -- Note: returns []string (immutable, readonly collection), not *string 115 | func someFunc(xs: []string) -> []string: 116 | -- This stream is available within the function, and is empty 117 | outside: *string 118 | for x <- xs: 119 | -- This stream is empty at the beginning of each iteration 120 | inside: *string 121 | 122 | -- We can manipulate the inside stream within the scope 123 | if x == "ok" 124 | inside <<- "ok" 125 | else: 126 | inside <<- "not ok" 127 | 128 | -- Read the value 129 | if inside! == "ok": 130 | outside <<- "result" 131 | 132 | -- outside stream is not escaping this function scope: 133 | -- it is converted to an array (canonicalized) and cannot be appended after that 134 | <- outside 135 | ``` 136 | 137 | You still can keep streams as streams by using them as `*string` arguments, or by returning them as `*string`. 138 | 139 | ### Note 140 | `data` types must be immutable, therefore streams are not allowed in the type declarations. 141 | -------------------------------------------------------------------------------- /docs/aqua-book/language/expressions/expressions.md: -------------------------------------------------------------------------------- 1 | # Expressions 2 | 3 | Aqua file consists of a header and a body. 4 | 5 | ## Body expressions 6 | 7 | `func` 8 | 9 | Function definition is the most crucial part of the language, see [Functions](functions.md) for details. 10 | 11 | [Expressions source code](https://github.com/fluencelabs/aqua/tree/main/semantics/src/main/scala/aqua/semantics/expr) 12 | -------------------------------------------------------------------------------- /docs/aqua-book/language/expressions/functions.md: -------------------------------------------------------------------------------- 1 | # Functions 2 | 3 | A function in Aqua is a block of code expressing a workflow, i.e., a coordination scenario that works across one or more peers. 4 | 5 | A function may take arguments of any type and may return a value. 6 | 7 | A function can call other functions, take functions as arguments of [arrow type](../types.md#arrow-types) and be provided as an arrow argument. 8 | 9 | Essentially, a function is an arrow. The function call is an expression that connects named arguments to an arrow, and gives a name to the result. 10 | 11 | In essense, all a function does is call its arguments or service functions. 12 | 13 | ```aqua 14 | service MySrv: 15 | foo() 16 | 17 | func do_something(): -- arrow of type: -> () 18 | MySrv "srv id" 19 | MySrv.foo() 20 | ``` 21 | 22 | -------------------------------------------------------------------------------- /docs/aqua-book/language/expressions/header.md: -------------------------------------------------------------------------------- 1 | # Header 2 | 3 | ## Header expressions 4 | 5 | ### `import` 6 | 7 | The `import` expression brings everything defined within the imported file into the scope. 8 | 9 | ```aqua 10 | import "path/to/file.aqua" 11 | ``` 12 | 13 | The to be imported file path is first resolved relative to the source file path followed by checking for an `-imports` directories. 14 | 15 | See [Imports & Exports](../header/header.md) for details. 16 | -------------------------------------------------------------------------------- /docs/aqua-book/language/expressions/overridable-constants.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: Static configuration pieces that affect compilation 3 | --- 4 | 5 | # Overridable constants 6 | 7 | ## `const` 8 | 9 | Constant definition. 10 | 11 | Constants can be used all across functions, exported and imported. If a constant is defined using `?=` , it can be overridden by value via compiler flags or imported values. 12 | 13 | ```aqua 14 | -- This can be overridden with --const 'TARGET_PEER_ID = "other peer id"' 15 | const TARGET_PEER_ID ?= "this is a target peer id" 16 | 17 | -- This constant cannot be overridden 18 | const SERVICE_ID = "service id" 19 | ``` 20 | 21 | You can assign only literals to constants. Constant type is the same as literal type. You can override only with a subtype of that literal type. 22 | -------------------------------------------------------------------------------- /docs/aqua-book/language/expressions/services.md: -------------------------------------------------------------------------------- 1 | # Services 2 | 3 | A service is a program running on a peer. Every service has an interface that consists of a list of functions. To call a service, the service must be identified: so, every service has an ID that must be resolved in the peer scope. 4 | 5 | In the service definition, you enumerate all the functions, their names, argument, and return types, and optionally provide the default Service ID. 6 | 7 | Services that are a part of the protocol, i.e. are available from the peer node, come along with IDs. Example of predefined service: 8 | 9 | ```aqua 10 | service Peer("peer"): 11 | foo() -- no arguments, no return 12 | bar(i: bool) -> bool 13 | 14 | func usePeer() -> bool: 15 | Peer.foo() -- results in a call of service "peer", function "foo", on current peer ID 16 | z <- Peer.bar(true) 17 | <- z 18 | ``` 19 | 20 | Example of a custom service: 21 | 22 | ```aqua 23 | service MyService: 24 | foo() 25 | bar(i: bool, z: i32) -> string 26 | 27 | func useMyService(k: i32) -> string: 28 | -- Need to tell the compiler what does "my service" mean in this scope 29 | MyService "my service id" 30 | MyService.foo() 31 | on "another peer id": 32 | -- Need to redefine MyService in scope of this peer as well 33 | MyService "another service id" 34 | z <- MyService.bar(false, k) 35 | <- z 36 | ``` 37 | 38 | Service definitions have types. Type of a service is a product type of arrows. See [Types](../types.md#type-of-a-service-and-a-file). 39 | -------------------------------------------------------------------------------- /docs/aqua-book/language/flow/conditional.md: -------------------------------------------------------------------------------- 1 | # Conditional 2 | 3 | Aqua supports branching, you can: 4 | - Check boolean expression with [`if`](#if) 5 | - Recover from error with [`try`](#try) or [`otherwise`](#otherwise) 6 | - Return different results with [conditional return](#conditional-return) 7 | 8 | ## Contract 9 | 10 | * The second branch of the conditional operator is executed if and only if the first block failed. 11 | * The second branch has no access to the first branch's data. 12 | * A conditional block is considered "executed" if and only if any branch was executed successfully. 13 | * A conditional block is considered "failed" if and only if the second (recovery) branch failed. 14 | 15 | ## Conditional operations 16 | 17 | ### `if` 18 | 19 | The first branch of the conditional operator, executed only if the condition holds. 20 | 21 | ```aqua 22 | x = true 23 | if x: 24 | -- always executed 25 | foo() 26 | 27 | if x == false: 28 | -- never executed 29 | bar() 30 | 31 | if x != false: 32 | -- always executed 33 | baz() 34 | ``` 35 | 36 | Any expression that produces `bool` is acceptable as a condition. 37 | 38 | `if` corresponds to `match`, `mismatch` extension of π-calculus. 39 | 40 | ### `else` 41 | 42 | The second branch of `if`, executed only in case the condition does not hold. 43 | 44 | ```aqua 45 | if false: 46 | foo() -- skipped 47 | else: 48 | bar() -- executed 49 | ``` 50 | 51 | If you want to set a variable based on condition, see [conditional return](#conditional-return). 52 | 53 | ### `try` 54 | 55 | Tries to perform operations, swallows produced error (if there's no `catch`, otherwise executes `catch`). 56 | 57 | ```aqua 58 | try: 59 | -- If foo fails with an error, execution will continue 60 | -- You should write your logic in a non-blocking fashion: 61 | -- If your code below depends on `x`, it may halt as `x` is not resolved. 62 | -- See conditional return below for workaround 63 | x <- foo() 64 | ``` 65 | 66 | ### `catch` 67 | 68 | Catches the standard error from the `try` block. 69 | 70 | ```aqua 71 | try: 72 | foo() 73 | catch e: 74 | logError(e) 75 | ``` 76 | 77 | Type of `e` is: 78 | 79 | ```aqua 80 | data LastError: 81 | instruction: string -- What AIR instruction failed 82 | msg: string -- Human-readable error message 83 | peer_id: string -- On what peer the error happened 84 | ``` 85 | 86 | ### `otherwise` 87 | 88 | You may add `otherwise` to provide recovery for any block or expression: 89 | 90 | ```aqua 91 | x <- foo() 92 | otherwise: 93 | -- if foo can't be executed, then do bar() 94 | y <- bar() 95 | ``` 96 | 97 | ## Conditional return 98 | 99 | In Aqua, functions may have only one return expression, which is the very last. 100 | 101 | So to get the value based on condition, we need to use a [writeable collection](../types.md#collection-types). 102 | 103 | ```aqua 104 | -- result may have 0 or more values of type string and is writeable 105 | resultBox: *string 106 | try: 107 | resultBox <- foo() 108 | otherwise: 109 | resultBox <- bar() 110 | 111 | -- now result contains only one value, let's extract it! 112 | result = resultBox! 113 | 114 | -- Type of result is string 115 | -- Please note that if there were no writes to resultBox, 116 | -- the first use of result will halt. 117 | -- So you need to be careful about it and ensure that there's always a value. 118 | ``` 119 | -------------------------------------------------------------------------------- /docs/aqua-book/language/flow/flow.md: -------------------------------------------------------------------------------- 1 | # Execution flow 2 | 3 | Aqua's main goal is to express how the execution flows: moves from peer to peer, forks to parallel flows and then joins back, uses data from one step in another. 4 | 5 | As the foundation of Aqua is based on π-calculus, finally flow is decomposed into [sequential](sequential.md) (`seq`, `.`), [conditional](conditional.md) (`xor`, `+`), [parallel](parallel.md) (`par`, `|`) computations and [iterations](iterative.md) based on data (`!P`). For each basic way to organize the flow, Aqua follows a set of rules to execute the operations: 6 | 7 | * What data is available for use? 8 | * What data is exported and can be used below? 9 | * How errors and failures are handled? 10 | 11 | These rules form a contract, as in [design-by-contract](https://en.wikipedia.org/wiki/Design_by_contract) programming. 12 | -------------------------------------------------------------------------------- /docs/aqua-book/language/flow/iterative.md: -------------------------------------------------------------------------------- 1 | # Iterative 2 | 3 | π-calculus has a notion of the repetitive process: `!P = P | !P`. That means, you can always fork a new `P` process if you need it. 4 | 5 | In Aqua, two operations correspond to it: you can call a service function (it's just available when it's needed), and you can use `for` loop to iterate on collections. 6 | 7 | ## `for` expression 8 | 9 | In short, `for` looks like the following: 10 | 11 | ```aqua 12 | xs: []string 13 | 14 | for x <- xs: 15 | y <- foo(x) 16 | 17 | -- x and y are not accessible there, you can even redefine them 18 | x <- bar() 19 | y <- baz() 20 | ``` 21 | 22 | ## Contract 23 | 24 | * Iterations of `for` loop are executed sequentially by default. 25 | * Variables defined inside `for` loop are not available outside. 26 | * `for` loop's code has access to all variables above. 27 | * `for` can be executed on a variable of any [Collection type](../types.md#collection-types). 28 | 29 | ### Conditional `for` 30 | 31 | For can be executed on a variable of any [Collection type](../types.md#collection-types). You can make several trials in a loop, and break once any trial succeeded. 32 | 33 | ```aqua 34 | xs: []string 35 | 36 | for x <- xs try: 37 | -- Will stop trying once foo succeeds 38 | foo(x) 39 | ``` 40 | 41 | The contract is changed as in [Parallel](parallel.md#contract) flow. 42 | 43 | ### Parallel `for` 44 | 45 | Running many operations in parallel is the most commonly used pattern for `for`. 46 | 47 | ```aqua 48 | xs: []string 49 | 50 | for x <- xs par: 51 | on x: 52 | foo() 53 | 54 | -- Once the fastest x succeeds, execution continues 55 | -- If you want to make the subsequent execution independent from for, 56 | -- mark it with par, e.g.: 57 | par continueWithBaz() 58 | ``` 59 | 60 | The contract is changed as in [Conditional](conditional.md#contract) flow. 61 | 62 | ### Export data from `for` 63 | 64 | The way to export data from `for` is the same as in [Conditional return](conditional.md#conditional-return) and [Race patterns](parallel.md#join-behavior). 65 | 66 | ```aqua 67 | xs: []string 68 | return: *string 69 | 70 | -- can be par, try, or nothing 71 | for x <- xs par: 72 | on x: 73 | return <- foo() 74 | 75 | -- Wait for 6 fastest results -- see Join behavior 76 | baz(return!5, return) 77 | ``` 78 | 79 | ### `for` on streams 80 | 81 | `for` on streams is one of the most advanced and powerful parts of Aqua. See [CRDT streams](../crdt-streams.md) for details. 82 | -------------------------------------------------------------------------------- /docs/aqua-book/language/flow/sequential.md: -------------------------------------------------------------------------------- 1 | # Sequential 2 | 3 | By default, Aqua code is executed line by line, sequentially. 4 | 5 | ## Contract 6 | 7 | * Data from the first line is available on the second line 8 | * A second line will be executed only if the first line succeeded 9 | * If any line failed, then the whole block is failed 10 | * If all lines succeeded, then the whole block is succeeded 11 | 12 | ```aqua 13 | f <- first() -- first line 14 | second(f) -- second line 15 | ``` 16 | 17 | _A block of code is any number of lines on the same indentation level or deeper._ 18 | 19 | ## Sequential operations 20 | 21 | ### call arrow 22 | 23 | Any runnable piece of code in Aqua is an arrow from its domain to the codomain. 24 | 25 | ```aqua 26 | -- Call a function 27 | foo() 28 | 29 | -- Call a function that returns something, assign results to a variable 30 | x <- foo() 31 | 32 | -- Call an ability function 33 | y <- Peer.identify() 34 | 35 | -- Pass an argument 36 | z <- Op.identity(y) 37 | ``` 38 | 39 | When you write `<-`, this means not just "assign results of the function on the right to variable on the left". It means that all the effects are executed: [service](../services.md) may change state, the [topology](../topology.md) may be shifted. But you end up being (semantically) on the same peer where you have called the arrow. 40 | 41 | ### on 42 | 43 | `on` denotes the peer where the code must be executed. `on` is handled sequentially, and the code inside is executed line by line by default. 44 | 45 | ```aqua 46 | func foo(): 47 | -- Will be executed where `foo` was executed 48 | bar() 49 | 50 | -- Move to another peer 51 | on another_peer: 52 | -- To call bar, we need to leave the peer where we were and get to another_peer 53 | -- It's done automatically 54 | bar() 55 | 56 | on third_peer via relay: 57 | -- This is executed on third_peer 58 | -- But we denote that to get to third_peer and to leave third_peer 59 | -- an additional hop is needed: get to relay, then to peer 60 | bar() 61 | 62 | -- Will be executed in the `foo` call site again 63 | -- To get from the previous `bar`, compiler will add a hop to relay 64 | bar() 65 | ``` 66 | 67 | See more in the [Topology](../topology.md) section. 68 | -------------------------------------------------------------------------------- /docs/aqua-book/language/header/header.md: -------------------------------------------------------------------------------- 1 | # Imports And Exports 2 | 3 | An Aqua source file has a header and a body. The body contains function definitions, services, types, constants. The header manages what is imported from other files and what is exported. 4 | 5 | ## Aqua source file header 6 | 7 | When header is omitted, `.aqua` file exports and declares everything it contains. With `aqua` header you can control what gets exported from the aqua file. 8 | 9 | ```aqua 10 | -- `aqua` expression may be only on the very first line of the file 11 | aqua AquaFile declares * 12 | ``` 13 | 14 | `Aqua.File` may contain dots. 15 | 16 | `AquaFile` can be used as the aqua's name when this file is `use`d. In this case, only what is enumerated in `declares` section will be available. `declares *` allows you to declare everything in the file as the module interface. 17 | 18 | ```aqua 19 | aqua AquaFile declares CONST_NAME, ServiceName, MyType, fn 20 | 21 | const CONST_NAME = "something" 22 | 23 | service ServiceName: 24 | do_something() 25 | 26 | data MyType: 27 | result: i32 28 | 29 | function fn() -> string: 30 | <- CONST_NAME 31 | ``` 32 | 33 | ## Import Expression 34 | 35 | The main way to import a file is via `import` expression: 36 | 37 | ```aqua 38 | import "@fluencelabs/aqua-lib/builtin.aqua" 39 | 40 | func foo(): 41 | Op.noop() 42 | ``` 43 | 44 | Aqua compiler takes a source directory and a list of import directories (usually with `node_modules` as a default). You can use relative paths to `.aqua` files, relatively to the current file's path, and to import folders. 45 | 46 | :::info 47 | `.aqua` extension in `import` and `use` expressions can be omitted. So, `import "builtin.aqua"` does exactly the same as `import "builtin"`. 48 | ::: 49 | 50 | Everything defined in the file is imported into the current namespace. 51 | 52 | You can cherry-pick and rename imports using `import ... from` expression: 53 | 54 | ```aqua 55 | import Op as Noop from "@fluencelabs/aqua-lib/builtin" 56 | 57 | func foo(): 58 | Noop.noop() 59 | ``` 60 | 61 | ## Use Expression 62 | 63 | The `use` expression makes it possible to import a file into a named scope. 64 | 65 | ```aqua 66 | use Op from "@fluencelabs/aqua-lib/builtin" as BuiltIn 67 | 68 | func foo(): 69 | BuiltIn.Op.noop() 70 | ``` 71 | 72 | If the imported file has a `aqua` header, `from` and `as` sections of `use` may be omitted. 73 | 74 | ```aqua 75 | use "@fluencelabs/aqua-lib/builtin.aqua" 76 | -- Assume that builtin.aqua's header is `aqua BuiltIn declares *` 77 | 78 | func foo(): 79 | BuiltIn.Op.noop() 80 | ``` 81 | 82 | ## Export 83 | 84 | While it's useful to split the code into several functions into different files, it's not always a good idea to compile everything into the host language. 85 | 86 | Another problem is libraries distribution. If a developer wants to deliver an `.aqua` library, he or she often needs to provide it in compiled form as well. 87 | 88 | `export` lets a developer decide what exactly is going to be exported, including imported functions. 89 | 90 | ```aqua 91 | import bar from "lib" 92 | 93 | -- Exported functions and services will be compiled for the host language 94 | -- You can use several `export` expressions 95 | export foo as my_foo 96 | export bar, MySrv 97 | 98 | service MySrv: 99 | call_something() 100 | 101 | func foo() -> bool: 102 | <- true 103 | ``` 104 | -------------------------------------------------------------------------------- /docs/aqua-book/language/language.md: -------------------------------------------------------------------------------- 1 | # Language 2 | 3 | Aqua is a language for distributed workflow coordination in p2p networks. 4 | 5 | It's structured with significant indentation: 6 | - Tabs and spaces are allowed simultaneously 7 | - Indentation of a parent block should be a strict prefix of indentation of a child block 8 | - First line in a block defines indentation and all consequent lines should have the same indentation 9 | 10 | ```aqua 11 | -- Comments begin with double-dash and end with the line (inline) 12 | func foo(): -- Comments are allowed almost everywhere 13 | -- Body of the block expression is indented 14 | bar(5) 15 | ``` 16 | 17 | Values in Aqua have types, which are designated by a colon, `:`, as seen in the function signature below. The type of a return, which is yielded when a function is executed, is denoted by an arrow pointing to the right `->` , whereas yielding is denoted by an arrow pointing to the left `<-`. 18 | 19 | ```aqua 20 | -- Define a function that yields a string 21 | func bar(arg: i16) -> string: 22 | -- Call a function 23 | someFunc(arg) 24 | 25 | -- Yield a value from a function 26 | x <- someFunc(arg) 27 | 28 | -- Return a yielded results from a function 29 | <- "return literal" 30 | ``` 31 | 32 | Subsequent sections explain the main parts of Aqua. 33 | 34 | Data: 35 | 36 | * [Types](types.md) 37 | * [Values of that types](values.md) 38 | 39 | Execution: 40 | 41 | * [Topology](topology.md) – how to express where the code should be executed 42 | * [Execution flow](flow/flow.md) – control structures 43 | 44 | Computations: 45 | 46 | * [Services](services.md) 47 | * [Abilities](abilities.md) 48 | 49 | Advanced parallelism: 50 | 51 | * [CRDT Streams](crdt-streams.md) 52 | 53 | Code management: 54 | 55 | * [Imports & exports](header/header.md) 56 | 57 | Reference: 58 | 59 | * [Expressions](expressions/expressions.md) 60 | -------------------------------------------------------------------------------- /docs/aqua-book/language/services.md: -------------------------------------------------------------------------------- 1 | # Services 2 | 3 | Services describe what can be called on peers, and how to call it. A service interfaces functions (often provided via WebAssembly interface) executable on a peer. Example of service definition: 4 | 5 | ```aqua 6 | service MyService: 7 | foo(arg: string) -> string 8 | bar() -> bool 9 | baz(arg: i32) 10 | ``` 11 | 12 | Service functions in Aqua have no function body. Computations, of any complexity, are implemented with any programming language that fits, and then brought to the Aqua execution context. Aqua calls these functions but does not peak into what's going on inside. 13 | 14 | ## Built-in Services 15 | 16 | Some services may be singletons available on all peers. Such services are called built-ins, and are always available in any scope. 17 | 18 | ```aqua 19 | -- Built-in service has a constant ID, so it's always resolved 20 | service Op("op"): 21 | noop() 22 | 23 | func foo(): 24 | -- Call the noop function of "op" service locally 25 | Op.noop() 26 | ``` 27 | 28 | ## Service Resolution 29 | 30 | A peer may host many services of the same type. To distinguish services from each other, Aqua requires Service resolution to be done: that means, the developer must provide an ID of the service to be used on the peer. 31 | 32 | ```aqua 33 | service MyService: 34 | noop() 35 | 36 | func foo(): 37 | -- Will fail 38 | MyService.noop() 39 | 40 | -- Resolve MyService: it has id "noop" 41 | MyService "noop" 42 | 43 | -- Can use it now 44 | MyService.noop() 45 | 46 | on "other peer": 47 | -- Should fail: we haven't resolved MyService ID on other peer 48 | MyService.noop() 49 | 50 | -- Resolve MyService on peer "other peer" 51 | MyService "other noop" 52 | MyService.noop() 53 | 54 | -- Moved back to initial peer, here MyService is resolved to "noop" 55 | MyService.noop() 56 | ``` 57 | 58 | There's no way to call an external function in Aqua without defining all the data types and the service type. One of the most convenient ways to do it is to generate Aqua types from Wasm code in Marine. 59 | -------------------------------------------------------------------------------- /docs/aqua-book/libraries/aqua-lib.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: API of protocol-level service (a.k.a builtins) 3 | --- 4 | 5 | # @fluencelabs/aqua-lib 6 | 7 | ## Releases 8 | 9 | You can find the latest releases of `aqua-lib` [on NPM](https://www.npmjs.com/package/@fluencelabs/aqua-lib) and changelogs are [on GitHub](https://github.com/fluencelabs/aqua-lib/releases) 10 | 11 | ## API 12 | 13 | The most up-to-date documentation of the API is in the code, please [check it out on GitHub](https://github.com/fluencelabs/aqua-lib/blob/main/builtin.aqua) 14 | 15 | ### Services 16 | 17 | `aqua-lib` defines a number of services available on peers in the Fluence Network: 18 | 19 | * `Op` - short for "Operations". Functions for data transformation. 20 | * `Peer` - functions affecting peer's internal state 21 | * `Kademlia` - functions to manipulate libp2p Kademlia 22 | * `Srv` - short for "Service". Functions for service manipulation 23 | * `Dist` - short for "Distribution". Functions for module and blueprint distribution 24 | * `Script` - functions to run and remove scheduled (recurring) scripts 25 | 26 | ## How to use it 27 | 28 | ### In Aqua 29 | 30 | Add `@fluencelabs/aqua-lib` to your dependencies as described in [Libraries doc](./libraries.md), and then import it in your Aqua script: 31 | 32 | ```aqua 33 | import "@fluencelabs/aqua-lib/builtin.aqua" 34 | 35 | -- gather Peer.identify from all nodes in the neighborhood 36 | func getPeersInfo() -> []Info: 37 | infos: *Info 38 | nodes <- Kademlia.neighborhood(INIT_PEER_ID, nil, nil) 39 | for node <- nodes: 40 | on node: 41 | infos <- Peer.identify() 42 | <- infos 43 | ``` 44 | 45 | ### In TypeScript 46 | 47 | `aqua-lib` is meant to be used to write Aqua scripts, and since`aqua-lib` doesn't export any top-level functions, it's not callable directly in the TypeScript. 48 | 49 | ## Patterns 50 | 51 | ### Functions With A Variable Number Of Arguments 52 | 53 | Currently, Aqua doesn't allow to define functions with a variable number of arguments. And that limits `aqua-lib` API. But there's a way around that. 54 | 55 | Let's take `Op.concat_strings` as an example. You can use it to concatenate several strings. `aqua-lib` provides the following signature: 56 | 57 | ```aqua 58 | concat_strings(a: string, b: string) -> string 59 | ``` 60 | 61 | Sometimes that is enough, but sometimes you need to concatenate more than 2 strings at a time. Happily, under the hood `concat_strings` accepts any number of arguments, so you can redeclare it with the number of arguments that you want: 62 | 63 | ```aqua 64 | service MyOp("op"): 65 | concat_strings(a: string, b: string, c: string, d: string) -> string 66 | ``` 67 | 68 | #### List of operations with a variable number of arguments 69 | 70 | Here's a full list of other Op-s that you can apply this pattern to 71 | 72 | * `Op.concat` - can concatenate any number of arrays 73 | * `Op.array` - wraps any number of arguments into an array 74 | * `Op.concat_string` - concatenates any number of strings 75 | -------------------------------------------------------------------------------- /docs/aqua-book/libraries/libraries.md: -------------------------------------------------------------------------------- 1 | # Libraries 2 | 3 | `import` declaration allows to use functions, services and data types defined in another module on the file system. While it's a very simple mechanic, together with NPM flexibility it enables full-blown package management in Aqua. 4 | 5 | ## Available Aqua Libraries 6 | 7 | * Builtin services API: [@fluencelabs/aqua-lib](aqua-lib.md) (see on [NPM](https://www.npmjs.com/package/@fluencelabs/aqua-lib)) 8 | * Registry: [@fluencelabs/registry](registry.md) (see on [NPM](https://www.npmjs.com/package/@fluencelabs/registry)) 9 | * IPFS API: [@fluencelabs/aqua-ipfs](aqua-ipfs.md) (see on [NPM](https://www.npmjs.com/package/@fluencelabs/aqua-ipfs)) 10 | 11 | ## How To Use Aqua Libraries 12 | 13 | To use a library, you need to download it by adding the library to `dependencies` in `package.json` and then running `npm install`. 14 | 15 | :::info 16 | If you're not familiar with NPM, `package.json` is a project definition file. You can specify `dependencies` to be downloaded from [npm](https://npmjs.org) and define custom commands (`scripts`), which can be executed from the command line, e.g. `npm run compile-aqua.` 17 | 18 | To create an NPM project, run `npm init`in a directory of your choice and follow the instructions. 19 | ::: 20 | 21 | Here's an example of adding `aqua-lib` to `package.json` dependencies: 22 | 23 | ```json 24 | { 25 | "name": "my-awesome-project", 26 | "version": "0.0.1", 27 | "dependencies": { 28 | "@fluencelabs/aqua-lib": "0.1.10" 29 | } 30 | } 31 | ``` 32 | 33 | After running `npm i`, you will have `@fluencelabs/aqua-lib` in `node_modules` 34 | 35 | ### In Aqua 36 | 37 | After the library is downloaded, you can import it in your `.aqua` script as documented in [Imports And Exports](../language/header/header.md): 38 | 39 | ```typescript 40 | import "@fluencelabs/aqua-lib/builtin.aqua" 41 | ``` 42 | 43 | Check out corresponding pages for the API of available libraries. 44 | 45 | ### In TypeScript and JavaScript 46 | 47 | To execute Aqua functions, you need to be connected to the Fluence network. The easiest way is to add JS SDK to `dependencies`: 48 | 49 | ```json 50 | "dependencies": { 51 | "@fluencelabs/registry": "0.3.2", 52 | "@fluencelabs/fluence": "0.21.5", 53 | "@fluencelabs/fluence-network-environment": "1.0.13" 54 | } 55 | ``` 56 | 57 | After executing `npm install`, the Aqua API is ready to use. Now you need to export `registry` functions to TypeScript, that's easy. Create a file `export.aqua`: 58 | 59 | ```aqua 60 | import createRouteAndRegisterBlocking, resolveRoute from "@fluencelabs/registry/routing.aqua" 61 | 62 | export createRouteAndRegisterBlocking, resolveRoute 63 | ``` 64 | 65 | Now, install Aqua compiler and compile your Aqua code to TypeScript: 66 | 67 | ```sh 68 | npm install --save-dev @fluencelabs/aqua 69 | aqua -i . -o src/generated/ 70 | ``` 71 | 72 | That's it. Now let's call some functions on the Registry service: 73 | 74 | ```typescript 75 | import { Fluence } from "@fluencelabs/fluence"; 76 | import { krasnodar } from "@fluencelabs/fluence-network-environment"; 77 | import { createRouteAndRegisterBlocking, resolveRoute } from "./generated/export"; 78 | 79 | async function main() { 80 | // connect to the Fluence network 81 | await Fluence.start({ connectTo: krasnodar[1] }); 82 | 83 | let label = "myLabel"; 84 | let value = "put anything useful here"; 85 | let serviceId = "Foo"; 86 | let ack = 5; 87 | 88 | // create route and register for it 89 | let relay = Fluence.getStatus().relayPeerId; 90 | let route_id = await createRouteAndRegisterBlocking( 91 | label, value, relay, serviceId, 92 | (s) => console.log(`node ${s} saved the record`), 93 | ack 94 | ); 95 | 96 | // this will contain peer as route provider 97 | let providers = await resolveRoute(route_id, ack); 98 | } 99 | 100 | main().then(() => process.exit(0)) 101 | .catch(error => { 102 | console.error(error); 103 | process.exit(1); 104 | }); 105 | 106 | ``` 107 | -------------------------------------------------------------------------------- /docs/aqua-book/libraries/registry.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: Aqua implementation of Fluence Registry and ResourcesAPI 3 | --- 4 | 5 | # @fluencelabs/registry 6 | 7 | Fluence Registry is an essential part of the Fluence network protocol. It provides a Resources API that can be used for service advertisement and discovery. For more details check out our [community call](https://www.youtube.com/watch?v=Md0_Ny_5_1o&t=770s). 8 | 9 | ## Releases 10 | 11 | You can find the latest `registry` release [on NPM](https://www.npmjs.com/package/@fluencelabs/registry) and the changelogs are in the [GitHub](https://github.com/fluencelabs/registry/releases) repo. 12 | 13 | ## API 14 | 15 | For the API implementation, take a look at [resources-api.aqua](https://github.com/fluencelabs/registry/blob/main/aqua/resources-api.aqua) in the `registry` repo. 16 | 17 | ## Learn 18 | 19 | You can checkout [README](https://github.com/fluencelabs/registry#readme) and follow the [example](https://github.com/fluencelabs/registry/tree/main/example#services-advertisement-and-discovery) -------------------------------------------------------------------------------- /docs/build/concepts/best_practices.md: -------------------------------------------------------------------------------- 1 | # Best Practices -------------------------------------------------------------------------------- /docs/build/concepts/fluence_functions_revisited.md: -------------------------------------------------------------------------------- 1 | # Fluence Functions Revisited -------------------------------------------------------------------------------- /docs/build/concepts/http_gateways.md: -------------------------------------------------------------------------------- 1 | # Handling HTTP Events -------------------------------------------------------------------------------- /docs/build/concepts/scheduling_functions.md: -------------------------------------------------------------------------------- 1 | # Scheduling Fluence Functions 2 | 3 | ## Introduction 4 | 5 | Like most serverless function, Fluence compute functions sit idle unless invoked. For the most part, event-based triggers will do the job, **link** to js-client. However, time-based triggers, such as cronjobs to poll some resource or simply wake up some other function at some pre-determined interval, are also a common source of function invocation. 6 | 7 | The Fluence Cloudless platform accommodates time-based triggers via Cloudless Scheduled Functions (aka spells). -------------------------------------------------------------------------------- /docs/build/concepts/security.md: -------------------------------------------------------------------------------- 1 | # Security -------------------------------------------------------------------------------- /docs/build/examples/frpc.md: -------------------------------------------------------------------------------- 1 | # Decentralized RPC With Fluence Functions 2 | 3 | Fluence's [fRPC Substrate](https://github.com/fluencelabs/frPC-Substrate) is a starter kit that includes all the components you need to quickly enable your dAPP with decentralized RPC using existing RPC as Service providers, e.g., Infura, Alchemy, QuickNode, etc., without having to modify your dApp's business logic or web3 libraries. -------------------------------------------------------------------------------- /docs/build/how-to/configure.md: -------------------------------------------------------------------------------- 1 | # Configure FLuence CLI -------------------------------------------------------------------------------- /docs/build/how-to/deploy.md: -------------------------------------------------------------------------------- 1 | # Deploy Your Fluence Functions -------------------------------------------------------------------------------- /docs/build/how-to/develop.md: -------------------------------------------------------------------------------- 1 | # Develop Your Fluence Functions 2 | 3 | -------------------------------------------------------------------------------- /docs/build/how-to/migrate.md: -------------------------------------------------------------------------------- 1 | # How To Migrate Your Deployed Fluence Functions -------------------------------------------------------------------------------- /docs/build/how-to/monitor.md: -------------------------------------------------------------------------------- 1 | # How To Monitor Your Fluence Functions 2 | -------------------------------------------------------------------------------- /docs/build/how-to/securing_functions.md: -------------------------------------------------------------------------------- 1 | # Secure your Fluence Functions -------------------------------------------------------------------------------- /docs/build/how-to/setting_up.md: -------------------------------------------------------------------------------- 1 | # Set Up Your Development Environment 2 | 3 | ## Overview 4 | 5 | Fluence provides an CLI that not only supports the scaffolding of development projects bu also manages a number of development dependencies including the Rust development tools necessary to code your business logic and compile to wasm-wasi. With respect to 6 | 7 | 8 | ## Fluence Tooling 9 | 10 | ### Preparing your system 11 | 12 | [node](https://nodejs.org/en/learn/getting-started/how-to-install-nodejs) 13 | 14 | ### FLuence CLI 15 | 16 | #### Install From Binary 17 | 18 | #### Install From Package Manager 19 | 20 | #### Install From Source 21 | 22 | 23 | ### VSCode Plug-In 24 | 25 | VSCode marketplace 26 | 27 | 28 | ## Crypto Wallet 29 | 30 | Note: Hopefully we won't need that 31 | 32 | ## Payment Account 33 | 34 | Fiat On Ramp: TBD 35 | 36 | -------------------------------------------------------------------------------- /docs/build/how-to/setup_payments.md: -------------------------------------------------------------------------------- 1 | # Manage Payments And Billing -------------------------------------------------------------------------------- /docs/build/how-to/test.md: -------------------------------------------------------------------------------- 1 | # Test Your Fluence Functions -------------------------------------------------------------------------------- /docs/build/overview/getting_started.md: -------------------------------------------------------------------------------- 1 | # Getting Started 2 | 3 | Let's explore the obligatory **Hello World** example as an end-to-end Fluence Cloudless App, which includes the following steps: 4 | 5 | * Scaffold a Fluence Cloud Function project with the [Fluence CLI](./../glossary#fluence-cli) 6 | * Create the Hello World example and compile it to Wasm 7 | * Distribute the Wasm module to capacity (hardware) providers 8 | * Execute your Fluence Functions Hello World application 9 | 10 | But first, let's get set up. 11 | 12 | ## Setting Up 13 | 14 | The recommended way to interact with the Fluence serverless network is to use the Fluence CLI. The CLI provides full lifecycle management for your Fluence Functions as well as your tooling and development dependencies. If you haven't installed the Fluence CLI already, use the install script provided below or check out the [Setting up](./../setting-up/setting_up.md) section. 15 | 16 | ```bash 17 | curl -qsL https://raw.githubusercontent.com/fluencelabs/cli/main/install.sh | bash 18 | ``` 19 | 20 | :::note 21 | Currently, Fluence CLI does not support Windows OS but supports Windows Linux Subsystem (WLS). 22 | ::: 23 | 24 | :::info 25 | During the installation process, you may be asked to provide *sudo* access to set the symlink for the binary. 26 | Alternative installation approaches can be found in the [Readme](https://github.com/fluencelabs/cli?tab=readme-ov-file#installation-and-usage). 27 | ::: 28 | 29 | After the installation process is complete, update the CLI with `fluence update stable` and check the version: 30 | 31 | ```bash 32 | fluence --version 33 | @fluencelabs/cli/0.15.10 darwin-arm64 node-v18.19.1 34 | ``` 35 | 36 | If you get the above CLI version, or higher, you are good to go. 37 | 38 | ## Hello World 39 | 40 | With the Fluence CLI installed, let's create our *hello world* project: 41 | 42 | ```bash 43 | fluence init hello-fluence 44 | ``` 45 | 46 | You will be asked to choose from different scaffolding templates: 47 | 48 | ```bash 49 | fluence init hello-fluence 50 | ? Select template (Use arrow keys) 51 | ❯ quickstart 52 | minimal 53 | ts 54 | js 55 | ``` 56 | 57 | Select the (default) *quickstart* template and in the subsequent network selection prompt continue to stay with the default (*kras*) network. Fluence CLI now scaffolds a project with the quickstart template and for the *kras* test network. Since this is your first use of the Fluence CLI, several dependencies may be downloaded and installed. Once the project has been successfully installed, you should see a message similar to: 58 | 59 | ```bash 60 | Successfully initialized Fluence CLI project template at
65 | 
70 |
71 |
72 | Enter the address of your wallet and, if you are using MetaMask, ask for the *tUSDC* token symbol to be imported. Then click the "Receive FLT & tUSDC" button. After a short delay, you should see a transaction id and the funds should be in your account.
73 |
74 | You are now equipped to pay for your Cloudless Deployment on the Fluence testnet!
--------------------------------------------------------------------------------
/docs/build/tutorials/event_handling_in_js.md:
--------------------------------------------------------------------------------
1 | # Event Handling In The Browser (Event Handling With Clients ?)
2 |
3 | The ubiquitous browser is the origin of a large number of diverse events, many of which are triggers for subsequent compute. In order to invoke Fluence Functions from the browser, we need to be able to somehow invoke Aqua scripts from the browser. This can be accomplished with the Fluence [js-client](https://github.com/fluencelabs/js-client). The *js-client* allows you to connect from the browser to the Fluence network and invoke the execution of the desired Aqua.
4 |
5 | ## Setting Up For The Browser
6 |
7 | Just like in the quickstart sections, we use Fluence CLI to scaffold out project with the appropriate template. Initialize the new project with:
8 |
9 | ```bash
10 | $ fluence init browser-events
11 | ```
12 | Choose the `ts` template and the default `kras` environment:
13 |
14 | ```bash
15 | ? Select template quickstart
16 | ? Select Fluence Environment to use by default with this project kras (default)
17 | <...>
18 | Successfully initialized Fluence CLI project template at /Users/bebo/localdev/fluence-code/mvm-docs-code/browser-events
19 | ```
20 |
21 | Before you `cd` into the new directory, recall that you also can non-interactively initialize the project with `fluence init -t ts --env kras
70 | 23 |
26 | 27 | This book is dedicated to all things in Marine and currently in its **alpha** version, stay in touch or contact us via the following channels: 28 | 29 | - [Telegram](https://t.me/fluence_project) 30 | - [Marine github](https://github.com/fluencelabs/marine) 31 | - [Youtube](https://www.youtube.com/channel/UC3b5eFyKRFlEMwSJ1BTjpbw) 32 | -------------------------------------------------------------------------------- /docs/marine-book/marine-runtime/api/api.md: -------------------------------------------------------------------------------- 1 | # API 2 | 3 | This section describes API of three main components of Marine: [Marine](marine-api.md), [Marine-JS](marine-js-api.md) and [core](core-api.md). 4 | -------------------------------------------------------------------------------- /docs/marine-book/marine-runtime/api/core-api.md: -------------------------------------------------------------------------------- 1 | import Tabs from "@theme/Tabs"; 2 | import TabItem from "@theme/TabItem"; 3 | 4 | # Core API 5 | 6 | This chapter briefly describes the API of the lowest layer of `Marine`. This layer is intended to provide the most basic API for module handling. The most functionality could be tested with a help of the Marine [REPL](../../marine-tooling-reference/marine-repl.md). 7 | 8 | ## Calling a module 9 | 10 | ```rust 11 | fn call( 12 | &mut self, 13 | module_name: impl AsRef
19 |
27 | {siteConfig.title}
20 |21 | {siteConfig.tagline} 22 |
23 | 24 | Get started 25 | 26 |