Constructors for CVM cells and related type predicate functions.

Convert cells to Clojure types.

Sometimes lossy since some cells do not have equivalents in Clojure. For instance, addresses are converted to long.
Recursive when it comes to collection.

Mainly useful for a deeper Clojure integration.

Code execution in the CVM, altering state, and gaining insights.

Central entities of this namespaces are contextes and they can be created using [[ctx]].

All other functions revolve around them. While the design of a context is mostly immutable, whenever an altering function
is applied (eg. [[juice-set]]) or code is handled in any way (eg. [[eval]]), old context must be discarded and only returned
one should be used.

Cheap copies can be created using [[fork]].

Actions involving code (eg. [[compile]], [[exec]], ...) return a new context which holds either a [[result]] or an [[exception]].
Those actions always consume [[juice]].

Given that a "cell" is the term reserved for CVM data and objects, execution consists of following steps:

| Step | Function | Does |
|---|---|---|
| 1 | [[expand]] | `cell` -> `canonical cell`, applies macros |
| 2 | [[compile]] | `canonical cell` -> `op`, preparing executable code |
| 3 | [[exec]] | Executes compiled code |

Any cell can be applied safely to those functions, worse that can happen is nothing (eg. providing an already compiled cell to
[[compile]]).

If fine-grained control is not needed and if source is not compiled anyways, a simpler alternative is to use [[eval]] which does
all the job.

When a CVM instance is used, it relies on a thread-local database which can be manually retrieved using [[local]].

The thread-local database can be set usint [[local-set]]. Originally, at thread initialization, it corresponds to
the [[global]] database which is common to all threads. Its value can also be altered using [[global-set]].

Ultimately, the [[global]] database itself returns [[default]] unless user has set its value to another database.

Default [[database]] is an Etch instance. See [[convex.db]].

Etch is a fast, immutable, append-only database specially tailored for cells.

This namespace provides an API for creating an instance by pointing to a single file. This file
hosts an arbitrarily large map of `hash of the encoding of a cell` -> `cell`. Hence, reading require
hashes (see `convex.cell/hash` from `:project/cvm`) and writes primarilty return refs or nil
when not found (see [[convex.ref]]).

Lastly, a root hash can be stored and retrieved. Cell stored at root is typically used to maintain
some sort of global state or table tracking what is needed.

**Attention.** By default, R/W functions use the current thread-local database (see [[convex.cvm.db]]).
Providing an instance explicitly is tricky because when reading, not all data might be retrieved at once.
This is what allows large data, even larger than memory, to be queried: large structures are split into refs
and not all refs are necessarily resolved right away. However, any unresolved ref will be resolved against
the current thread-local database when needed, not the one that was explicitly provided when reading.

In other words, when handling a custom instance, it is best to work on a dedicated thread and call
[[convex.cvm.db/local-set]].

That being said, instances support multithreading. Being immutable, no thread has to worry that some data might
be removed or updated in place.

Reading, parsing various kind of sources into CVX cells without any evaluation.

Attention, currently, functions that read only one cell fail when the input contains more than one.
In the future, behavior should be improved. For instance, consuming cells one by one from a stream.

Also see the [[convex.write]] namespace for the opposite idea.

A `ref` is a reference to a cell. Most of the time, is it used as an intermediary value between a database
and the CVM. Unless refs are handled in reference to an explicit database, database used when resolving is always the current
one bound to the local thread. See [[convex.cvm.db]], [[convex.db]].

A **direct ref** holds a direct reference to a cell whereas a **soft ref** might release its reference when there is pressure
on memory. If needed, a **soft ref** will fetch its corresponding cell from a database.

Provides an API for cells with classic `convex.core` functions such as [[conj]].

All `clojure.core` functions related to sequences usually understand Convex collections, making them
easy to handle. Some of those (eg. `cons`, `next`) have counterparts in this namespace in case the return
value must be a cell instead of a Clojure sequence.

Functions take and return cells unless specified otherwise. Predicates return JVM booleans.

Sometimes, it can be useful converting cells to Clojure data, such as unwrapping blob to byte arrays,
which is the purpose of the [[convex.clj]] namespace.

Lastly, in the rare cases where all of this would not be enough, Java interop can be used:

  https://www.javadoc.io/doc/world.convex/convex-core/latest/convex/core/data/package-summary.html

Writing, encoding CVX cells various kind of sources.

Binary is big-endian and text is UTF-8.

Also see [[convex.read]] for the opposite idea.