Morloc Manual

Morloc allows functions from polyglot libraries to be composed in a simple functional language. The focus isn’t on classic interoperability (e.g., calling Python from C) or serialization (e.g., sending data between applications via protobufs) — though morloc implementations may use these under the hood. Instead, you define types, import implementations, and build complex programs through function composition. The compiler invisibly generates any required interop code.

Do you want to write in language X but have to write in language Y because everyone in your team does or because your expected users do? Love C for algorithms, R for statistics, but don’t want to write full apps in either? Morloc lets you mix and match, so you can use each language where it shines, with no bindings or boilerplate.

Tired of learning new benchmark and testing suites across all your languages? Is it hard to benchmark similar tools wrapped in applications with varying input formats, input validation costs, or startup overhead? In Morloc, functions with the same general type signature can be swapped in and out for benchmarking and testing. The same test suites and test cases will work across all supported languages because inputs/output of all functions of the same type share equivalent Morloc binary forms, making validation and comparison easy.

With Morloc, we can build abstract libraries using the general types as a logical framework. Then we can import implementations of these functions from one or more of the supported languages and easily test and benchmark them. These libraries are the foundation for an ecosystem where functions may be verified, organized/searched by type, and used to build rigorous programs.

Within the bioinformatics space, Morloc can serve as a replacement for the brittle application/file paradigm of workflow design. Replace heavy CLI applications with pure function libraries, ad hoc textual file formats with explicit data structures, and workflow specifications with function compositions. See the the first Morloc paper for details (pre-released here).

The easiest way to run Morloc is through containers in a UNIX environment. Linux will work natively. MacOS and Windows are more complicated and I’ll deal with their special later on. For Windows, you will need to install through the Windows Subsystem for Linux.

The only dependency is a container engine, currently two — docker and podman — are supported.

After confirming either Podman or Docker is running on your system, pull an installation script from morloc-project/morloc-manager:

morloc-manager is a (mostly) POSIX compatible shell script that is tested on Linux and MacOS. On Windows, you should may run this in the Windows Subsystem for Linux (WSL). You may execute morloc-manager directly, for example bash morloc-manager. But it is more convenient to make the script executable and move it to a folder in your execution path.

The script provides usage information on request:

The install subcommand will build the Morloc home directory, install required containers, and generate executable scripts. The two you need are menv and morloc-shell.

menv runs arbitrary commands in a Morloc container. It can be used to compile and run Morloc programs. For example:

morloc-shell is the same as the above script except that you enter the container in an interactive shell rather than just running one command. The container has installations for Python, R, and C++ compiler as well as vim and other conveniences.

We are currently working on expanding the editor support for Morloc.

Here are supported editors

I’ve also written several syntax highlighting and static analysis tools:

The inevitable "Hello World" case is implemented in Morloc like so:

The module named main exports the term hello which is assigned to a literal string value.

Paste this code into a file (e.g. "hello.loc") and then it can be imported by other Morloc modules or directly compiled into a program where every exported term is a subcommand.

This command will produce an executable named nexus (a copy of the pre-compiled nexus binary) along with a nexus.manifest JSON file and pool files for each language used (e.g., pool.py, pool-cpp.out, pool.R). The nexus is the command line interface (CLI) to the commands exported from the module.

Calling nexus with no arguments or with the -h flag, will print a help message:

This usage message is automatically generated. For each exported term, it specifies the input (none, in this case) and output types as inferred by the compiler. For this case, the exported command is just the term hello, so no input types are listed.

The command is called as so:

Let’s write a little program rolls a pair of 20-sided dice and prints the larger result. Here is the Morloc script:

Here we define a module named dnd that exports the function rollAdv. In line 2, we import the required type definitions from the Morloc module types. Later on we’ll go into how these types are defined. In line 3, we source three functions from the Python file "foo.py". In lines 5-8, we assign each of these functions a Morloc type signature. You can think of the arrows in the signatures as separating arguments. For example, the function roll takes two integers as arguments and returns a list of integers. The square brackets indicate lists. In the final line, we define the rollAdv function.

The Python functions are sourced from the Python file "foo.py" with the following code:

Nothing about this code is particular to Morloc.

One of Morloc’s core values is that foreign source code never needs to know anything about the Morloc ecosystem. Sourced code should always be nearly idiomatic code that uses normal data types. The inputs and outputs of these functions are natural Python integers, lists, and strings — they are not Morloc-specific serialized data or ad hoc textual formats.

This module is dependent on the types module, which in turn is dependent on the prelude module. So before compiling, we need to import both of these:

Now we can compile and run this program as so:

As a random function, it will return a new result every time.

So, what’s the point? We could have done this more easily in a pure Python script. Morloc generates a CLI for us, type checks the program, and performs some runtime validation (by default, just on the final inputs and outputs). But there are other tools in the Python universe can achieve this same end. Where Morloc is uniquely valuable is in the polyglot setting.

In this next example, we rewrite the prior dice example with all three functions being sourced from different languages:

Note that all of this code is exactly the same as in the prior example except the source statements.

The roll function is defined in R:

The max function is defined in C++:

The narrate function is defined in Python:

This can be compiled and run in exactly the same way as the prior monoglot example. It will run a bit slower, mostly because of the heavy cost of starting the R interpreter.

The Morloc compiler automatically generates all code required to translate data between the languages. Exactly how this is done will be discussed later.

Here is an example showing a parallel map function written in Python that calls C++ functions.

This Morloc script exports a function that sums a list of lists of real numbers. Here we use the dot operator for function composition. The sum function is implemented in C++:

The parallel pmap function is written in Python:

The inner summation jobs will be run in parallel. The pmap function has the same signature as the non-parallel map function, so can serve as a drop-in replacement.

This can be compiled and run with the lists being provided in JSON format:

Morloc supports standard primitives, homogenous lists, and tuples.

Booleans in Morloc are represented as True or False under the Bool type.

Numbers may be represented in normal format, scientific notation, or as hexidecimal/octal/binary format:

Morloc supports multi-line strings and string interpolation.

String interpolation uses the #{…​} syntax. The expression inside the braces must evaluate to a Str:

String interpolation works with any expression that returns a string.

Multi-line strings use triple quotes. Leading indentation common to all lines is stripped:

Tuples may be used to store a fixed number of terms of different type.

Records are essentially named tuples. Record type definitions and language-specific handling will be addressed later, but record data is expressed as shown in the example below:

Lists are used to store a variable number of terms of the same type.

Lists do not yet have special accessors (e.g., slicing). List operations are performed through sourced functions such as head, tail, take, etc. You may import many of these from the root modules.

Data structures may be accessed and modified using pattern functions. These patterns may be getters that extract a tuple of values from a data structure or setters that update a data structure without changing its type.

A getter pattern describes an optionally branching path into a data structure. Each segment of the path may be a tuple index, a record key, or a group of indices/keys. The terminal positions in the pattern are returned as elements in a tuple. Here are a few examples:

These patterns are transformed into functions may be used exactly like any other function.

Setter patterns are similar but add an assignment statement to each pattern terminus.

Note that setters are designed to not mutate data. The spine of the data structure will be copied which retains links to the original data for unmodified fields. So the expression .(.0 = 42) x when translated into Python will create a new tuple with the first field being 42 and the remaining fields assigned to elements of the original field. The same goes for records.

In Morloc, you can import functions from many languages and compose them under a common type system. The syntax for importing functions from source files is as follows:

This brings the functions map, sum, and snd into scope in the Morloc script. Each of these functions must be defined in the C++ and Python scripts. For Python, since map and sum are builtins, only snd needs to be defined. So the foo.py function only requires the following two lines:

The C++ file, foo.hpp, may be implemented as a simple header file with generic implementations of the three required functions.

Note that these implementations are completely independent of Morloc — they have no special constraints, they operate on perfectly normal native data structures, and their usage is not limited to the Morloc ecosystem. The Morloc compiler is responsible for mapping data between the languages. But to do this, Morloc needs a little information about the function types. This is provided by the general type signatures, like so:

The syntax for these type signatures is inspired by Haskell, with the exception that generic terms (a and b here) must be declared on the left. Square brackets represent homogenous lists and parenthesized, comma-separated values represent tuples, and arrows represent functions. In the map type, (a → b) is a function from generic value a to generic value b; [a] is the input list of initial values; [b] is the output list of transformed values.

Removing the syntactic sugar for lists and tuples, the signatures may be written as:

These signatures provide the general types of the functions. But one general type may map to multiple native, language-specific types. So we need to provide an explicit mapping from general to native types.

These type functions guide the synthesis of native types from general types. Take the C++ mapping for List a as an example. The basic C++ list type is vector from the standard template library. After the Morloc typechecker has solved for the type of the generic parameter a, and recursively converted it to C++, its type will be substituted for $1. So if a is inferred to be a Real, it will map to the C++ double, and then be substituted into the list type yielding std::vector<double>. This type will be used in the generated C++ code.

Functions are defined with arguments seperated by whitespace:

Here foo is the Morloc function name and x is its first argument.

The Morloc internal module, which is imported into all root modules, defines the composition (.) and application ($) operators.

With . , we can re-write foo as:

Composition chains can build multi-stage pipelines:

The $ operator is the application operator. It has the lowest precedence, so it can be used to avoid parentheses:

Morloc supports partial application of arguments.

For example, to multiply every element in a list by 2, we can write:

Partial application works well for leading arguments, but what if we want to partially apply a later argument?

For example, we can use direct partial application with subtraction to create functions that subtract the input argument from a given value:

But what if we want to do the reverse:

One solution is to use anonymous function, lambdas, like so:

Morloc also supports a shortcut for more flexible partial application using underscores as placeholders:

This will be transformed in the compiler frontend to a lambda, so is behaves identically. These placeholders may also be used in data structures. The following two expressions obtain the same result:

The placeholders may be used in nested data structures as well:

When multiple placeholders are used, the arguments generated for the lambda are applied in left-to-right order.

Placeholders also work in string interpolation:

While Morloc’s primary purpose is composing foreign functions, you can also define functions entirely in Morloc without sourcing from any language. These native functions are written using Morloc’s own expression syntax:

Native functions can use composition, where clauses, lambdas, and all other Morloc expression forms. They are compiled down to whichever language the compiler selects for execution.

Functions may use where clauses to define local bindings:

Where clauses inherit the scope of their parent and may be nested:

let is the more orderly cousin of where. The where clause defines terms that can be used anywhere in the where block and that may be any functional argument.

let also allows you to ignore the result of a computation:

Ignoring the return data from n+1 is completely pointless in this case, but this ability will become crucial when we move on with computational that have side-effects. === Guards

Guards provide conditional branching within function definitions. Each guard clause begins with ? followed by a condition and a result expression, with a : default that is always required as the final case:

Guards are evaluated lazily from top to bottom. The first condition that evaluates to true determines the result; remaining guards are not evaluated. The : default always terminates the guard chain, ensuring exhaustiveness.

Guards work naturally with multiple parameters:

Guards can be combined with where clauses to define local bindings used in the conditions and result expressions:

Guards may appear inside let bindings:

Guards can also be used as inline expressions anywhere a value is expected, enclosed in parentheses:

Morloc supports recursive function definitions. A function may refer to itself in its body, and the compiler will generate the appropriate code in the target language.

The classic factorial function can be written using guards and self-reference:

Functions may also be mutually recursive. The following pair of functions determines (rather inefficiently) whether a number is even or odd:

Morloc supports user-defined infix operators with explicit associativity and precedence. Operators are declared with infixl (left-associative) or infixr (right-associative) followed by a precedence level (higher binds tighter):

Operators are given type signatures by wrapping them in parentheses:

Operators may be sourced from foreign languages like any other function:

Infix operators work naturally with typeclasses:

Operators may also be imported from other modules:

A record is internally a named tuple. Records may map to different structures in different languages.

A general record is defined as follows:

Concrete forms must have the same field names and field types. Since these must be the same, they need not be specified. We only need to specify the name of the concrete type:

In R and Python, records are typically dict and list types, respectively. These types con contain any fields of any type. In C++, records are represented as structs; these must must be defined in the C code, as shown below.

Functions may be defined that act on the records, as below:

Records may, like all morloc types, be passed freely between languages. As shown above, records may be written in braces and their type will be inferred.

The "foo.R" file contains the function:

No special code is needed for person, it is just a builtin R list. Similarly for Python:

C++ requires a definition of a person_t struct:

Records may be initialized and functions called on them:

foo, above, initializes a Person record and then increments its age 3 time in different languages.

Records may contain fields with arbitrarily complex types, but recursive types are not currently supported.

Tables are similar, but all fields are lists of equal length:

With "people-tables.R" containing:

This can be compiled and run as so:

The record and table types are currently strict. Defining functions that add or remove fields/columns requires defining entirely new records/tables. Generic functions for operations such as removing lists of columns cannot be defined at all. For now, most operations should be done in coarser functions. Alternatively, custom non-parameterized tabular/record types may be defined.

The case study in the Morloc paper uses a JsonObj type that represents an arbitrarily nested object that serializes to/from JSON. In Python, it deserializes to a dict object; in R, to a list objects; and in C to an ordered_json object from from (Niels Lohmann’s json package).

A similar approach could be used to define a non-parameterized table type that serialized to CSV or some binary type (such as Parquet).

These non-parameterized solutions are flexible and easy to use, but lack the reliability of the typed structures.

Morloc is a functional programming language. Here a "function" is a mapping from a value in one domain to value in another domain. This works neatly for pure functions. But it becomes complicated when "effects", like interactions with the operating system, are introduced.

Consider a simple readFile program:

This Morloc program takes a filename as input and returns a string containing the file contents. Logically, this is a function. You are mapping a filename to the file contents. At a given slice of time on a given system, there is a one-to-one mapping between filenames and files.

You can save the contents in a variable:

contents is now a value storing a string. But the world is not constant. Files change. Let’s say that myfile.txt is a log file and we want to read it at multiple time points. Further, we don’t want to specify the filename every time we call the function. It would be more convenient to partially apply the filename and have a function that will map the applied filename to whatever is currently at the file location. But partially applying the filename to readFile results in a value not a function. In many familiar languages, you can define functions that have no arguments. So you could call read_log() and it would read the log and return a fresh contents blob every time the function was executed.

Let’s look at an even trickier problem. Suppose we wanted a function that returns the current epoch time. How would this be defined in Morloc? You could require arguments that transform the problem to a true function. The world state could be an argument. This state might be the locale or some other reference. The function then becomes

But once again, when we partially apply the function, we again are reduced to a value. Perhaps we want a "function" that always returns California time.

A second example is random numbers. We can define a family of random functions like so:

runif and choose are functions that produce random values when given the required arguments. But what is coinToss? There are no arguments. Again, you could reparameterize these random functions as pure functions that take a random seed, or a stateful random generator, as an argument. That would look something like this:

This is the "right" way to do random effects. But it is certainly not the most common way of doing it. In most languages, the random number generator exists in global state. Or the random number generator might use actual system noise to get truly random values.

What we want in Morloc is to preserve the power of partial function application but still have the ability to call "functions" with no arguments. We can achieve this by preventing a term from being evaluated until we explicitly request evaluation.

In Morloc, delayed computatoin is specified with braces at both the type-level and the term-level. So you can write the (rather pointless) expression:

This defins an expression that evaluates to the value 42 whenever its value is requested. There are two ways to request evaluation. First, the top value in an program is implicitly forced. Here is val is directly exported in the compiled program, the command ./nexus val will return 42. The second way is to force evaluation with !val.

Let’s look at a less trivial cases:

Let’s dig more into the final function. The roll2d20 initializes with two rolls. It is fully evaluated. What if we want an expression that always evaluates to a fresh pair of 2d20 rolls? For this we can wrap the expression in braces.

The braces around the expression indicates that its evaluation is suspended until forced. Once it is forced to evaluate, the inner rolls are forced as well, leading to fresh dice rolls.

What if we have more complex sets of effects? Perhaps we have many rolls that need to be used in conditionals. Let’s say we want to simulate damage in a DnD attack. If the attack d20 roll is greater than the enemy’s defense, then the attack hits and does damage equal to base damage plus the sum of the rolled attack dice. We could write all this into a suspended expression:

This works. But what if we add we add in terms that exist just for their side effects. Suppose we are writing a shellscript-like sequence of commands. Maybe we want to make a directory, move into the directory, create a file, and echo something into it. Here we need to sequence effects.

This works. The let syntax forces evaluation in a specific order and the let wildcard allows results to be ignored (though here, we should probably not be ignoring the exit code).

Morloc also has a do syntax that allows a more imperative approach:

Note that the expression type is delayed, so we can control when this computation is evaluated.

Here is one last example that shows several ways to implement the same problem

All programming languages must have a way to deal with missing values. If you query a database for a record that doesn’t exist, what is returned? If a parameter is not set, what value does it have? In Python, the None type stores missing values. In R, NULL serves a similar purpose. In both languages, types that may lack values are represented as a union of the original type and the null type. JSON, similarly, stores missing values as null. Other languages solve this problem in libraries. C++ has the standard template library datastructure std::optional<T> for representing values of generic type T that have null, std::nullopt types.

Haskell offers the Maybe sum type that may be Nothing or Just a. This is perhaps the cleanest solution, but it is not practical for Morloc. One of the core principles of Morloc is that sourced functions should be idiomatic. So Morloc needs a built-in mechanism that can vary freely in language-specific implementation while preserving between language consistency. To this end, Morloc offers a dedicated "Optional" type with supported implicit coercion.

In some cases, there is a single obvious native type for a given Morloc general type. For example, most languages have exactly only one reasonable way to represent a boolean. However, other data types have may have many forms. The Morloc List is a simple example. In Python, the list type is most often used for representing ordered lists, however it is inefficient for heavy numeric problems. In such cases, it is better to use a numpy vector. Further, there are data structures that are isomorphic to lists but that are more efficient for certain problems, such as stacks and queues.

We can define type hierarchies that represent these relationships.

Here we equate each of the specialized containers with the general List type. This indicates that they all share the same common form and can all be converted to the same binary. Then we specify language specific patterns as desired. When the Morloc compiler seeks a native form for a type, it will evaluate these type functions by incremental steps. At each step the compiler first checks to see if there is a direct native mapping for the language, if none is found, it evaluates the general type function.

Native type annotations are also passed to the language binders, allowing them to implement specialized behavior for more efficient conversion to binary.

Morloc supports what might be called term polymorphism. Each term may have many definitions. For example, the function mean has three definitions below:

mean is sourced directly from C++, it is defined in terms of the sum function, and it is defined more generally with sum written as a fold operation. The Morloc compiler is responsible for deciding which implementation to use.

The equals operator in Morloc indicates functional substitutability. When you say a term is "equal" to something, you are giving the compiler an option for what may be substituted for the term. The function mean, for example, has many functionally equivalent definitions. They may be in different languages, or they may be more optimal in different situations.

Now this ability to simply state that two things are the same can be abused. The following statement is syntactically allowed in Morloc:

What is x after this code is run? It is 1 or 2. The latter definition does not mask the former, it appends the former. Now in this case, the two values are certainly not substitutable. Morloc has a simple value checker that will catch this type of primitive contradition. However, the value checker cannot yet catch more nuanced errors, such as:

In this case, the type checker cannot check whithin the implementation of add, so it cannot know that there is a contradiction. For this reason, some care is needed in making these definitions.

In addition to term polymorphism, Morloc offers more traditional ad hoc polymorphism over types. Here typeclasses may be defined and type-specific instances may be given. This idea is similar to typeclasses in Haskell, traits in Rust, interfaces in Java, and concepts in C++.

In the example below, Addable and Foldable classes are defined and used to create a polymorphic sum function.

The instances may import implementations for many languages.

The native functions may themselves be polymorphic, so the imported implementations may be repeated across many instances. For example, the Python add may be written as:

And the C++ add as:

Typeclasses may be imported from other modules. For example, a module that defines the Ord typeclass and derived operators can be imported and instantiated in another module:

Types that are composed entirely of Morloc primitives, lists, tuples, records and tables may be directly and unambiguously translated to Morloc binary forms and thus shared between languages. But what about types that do not break down cleanly into these forms? For example, consider the parameterized Map k v type that represents a collection with keys of generic type k and values of generic type v. This type may have many representations, including a list of pairs, a pair of columns, a binary tree, and a hashmap. In order for Morloc to know how to convert all Map types in all languages to one form, it must know how to express Map type in terms of more primitive types. The user can provide this information by defining instances of the Packable typeclass for Map. This typeclass defines two functions, pack and unpack, that construct and deconstruct a complex type.

The Map type for Python and C++ may be defined as follows:

The Morloc user never needs to directly apply the pack and unpack functions. Rather, these are used by the compiler within the generated code. The compiler constructs a serialization tree from the general type and from this trees generates the native code needed to (un)pack types recursively until only primitive types remain. These may then be directly translated to Morloc binary using the language-specific binding libraries.

In some cases, the native type may not be as generic as the general type. Or you may want to add specialized (un)packers. In such cases, you can define more specialized instances of Packable. For example, if the R Map type is defined as an R list, then keys can only be strings. Any other type should raise an error. So we can write:

Now whenever the key generic type of Map is inferred to be anything other than a string, all R implementations will be pruned.

When a function is sourced from a foreign language, Morloc needs to know how Morloc general types map to the function’s native types. This information is encoded in language-specific type functions. For examples:

Language-specific types are always quoted since they may contain syntax that is illegal in the Morloc language.

A function such as an integer addition function addInt:

This can be automatically mapped to a C++ function with the prototype int addInt(int x, int y).

Containers can be similarly mapped to native types:

The $1 symbol is used to represent the interpolation of the first parameter into the native type. So the Morloc type List Int32 would translate to std::vector<uint32_t> in C++.

A Morloc module describes a set of functions, their types, and their descriptions. We’ve already covered terms and types, now we will cover the descriptions we add to modules, functions, arguments and fields. The extra data is stored in specialized comments (docstrings) that describe the terms and add modifications like defaults. The most obvious use case of these annotations is in specializing CLI interfaces, discussed in the next section, but they aslo inform the generation of rich APIs as well (see the HTTP/TCP/socket section).

Building a Morloc module will generate a CLI tool where exported functions are presented as typed subcommands.

Here is a minimal example of propagated function descriptions:

The special comment --' introduces a docstring that is attached to the following type signature and will be propagated through to the code generated by the backend.

More detailed information about each exported subcommand may be accessed as well:

Docstrings may also contain tags that specify how the arguments of the exported functions map to CLI positional or optional arguments. Here is a list of the currently supported tags:

Here is a longer example that show-cases these tags:

The top-level usage statement is as follows

The dedicated usage information for foo can be accessed as well. Here we see that the record Config has been unrolled into a group of optional arguments:

Since each subcommand is a function, the return type is always the same. Unlike in a conventional CLI program, the arguments cannot alter the return type.

The bar subcommand explicitly does not unroll the Config record:

Since modules can both be compiled into executable command line tools and imported by other modules, we can naturally compose command line tools.

Here is a little Morloc script that imports a Python program that prints a calendar to STDERR.

Here is another Morloc tool that prints d20 rolls

Now we can import both of these into a third module which will expose the functions from both the calendar and dnd modules.

This final module can be compiled and will have a usage statement like so:

User data is passed to Morloc executables as positional arguments to the specified function subcommand. The argument may be a literal JSON string or a filename. For files, the format may be JSON, MessagePack, or Morloc binary (VoidStar) format. The Morloc nexus first checks for a ".json" extension, if found, the nexus attempts to parse the file as JSON. Next the nexus checks for a ".mpk" or ".msgpack" extension, and if found it attempts to parse the file as a MessagePack file. If neither extension is found, it attempts to parse the file first as Morloc binary, then as MessagePack, and finally as JSON. See the parse_cli_data_argument function in morloc.h for details.

Passing literal JSON on the command line can be a little unintuitive since extra quoting may be required. Here are a few examples:

Data may be written to MessagePack or VoidStar via the -f argument:

The VoidStar format is the richest and is the only form that contains the schema describing the data.

The docstrings are used for discoverability as well. In this section I’ll cover how modules are installed as executables or standard modules and how they can be searched.

I’ll demonstrate this with a simple two module Morloc program describing a set of DnD operations. The first module defines general random operations:

The sourced fate.py script contains the following code:

We can install fate with morloc install --build ./fate. This create the morloc module we will need in the future as well as an executable we can test.

We can test this, for example by rolling 3d8:

Next let’s build on this foundation. First let’s make a simple tavern script that helps generate new characters.

Next let’s add a module for combat:

We can build just the CLI tools if we wish:

This will build the executable combat which is a script that carries with it all the information needed for execution. You can copy it anywhere you like on the system and it will work (so long as the contents of the directory where it was made are preserved). If you want, you can move the executable to a location in your system PATH and then you can call it as a normal program from anywhere.

But Morloc offers a cleaner solution:

This command does several things.

First it installs the combat executable to a standard path. The pool/ artifacts and all files in the current working directory need to be moved to a standard location. There are two ways you can specify the required build files.

You can specify required files with --include arguments

Or you can create a package.yaml file and add an include field. The default file can be generaed for you with morloc new. You can then modify the include field list with the required files:

Then run morloc make --install combat.loc.

In both install paths, the combat source code is copied to the ~/.local/share/morloc/exe/<modname> folder and the executable script itself is written to ~/.local/share/morloc/bin/.

We can view the installed executable:

If we add the Morloc bin folder above to PATH, then we can now use this program naturally:

We can also uninstall with morloc uninstall combat. This will cleanly remove the installed source and the installed executable script.

In addition to being CLI tools, compiled Morloc programs can run as long-lived daemons, accepting function calls over HTTP, TCP, or Unix sockets. A router aggregates multiple programs behind a single API.

No extra steps are needed to setup these extra APIs. They are already built into the executable we created in the last session. We only need to activate them.