Placeholder ns so we can use it for aliasing in clojure 1.10 and below

An implementation of the W3C SCXML Recommended Spec from 2015-09-01.

Uses an imperative style (internally) to match the pseudocode in the standard for easier translation,
verification, and avoidance of subtle differences in implementation.

Main mechanism to define and navigate a statechart definition. The processing algorithm for such
a statechart is protocol-based. The v20150901 implementation is the default.

::sc/k in the docstrings of this namespace assumes the alias `[com.fulcrologic.statecharts :as sc]`, which
can be generated as only an alias, though an empty namespace of that name does exist.

ALPHA. NOT API STABLE.

This namespace includes functions and macros that emit statechart elements, but have a more
concise notation for common cases that are normally a bit verbose.

Another purpose that is built into some of the macros is to make it more convenient to get clear diagram output
when rendering the chart (TODO). The `choice` macro, for example, includes the conditional expressions as
strigified notes on the nodes.

ALPHA. NOT API STABLE.

This namespace includes functions and macros that emit statechart elements, but have a more
concise notation for common cases that are normally a bit verbose.

Another purpose that is built into some of the macros is to make it more convenient to get clear diagram output
when rendering the chart (TODO). The `choice` macro, for example, includes the conditional expressions as
strigified notes on the nodes.

Convenience helpers for interacting with `DataModel`s

An implementation of DataModel that stores the data in working memory itself.

Supports using `src` in data model for CLJ ONLY, which must be a URI that clojure.java.io/reader
would accept.

There are two implementations: One where data is scoped to the state, and another where it is global.

The elements you can define in charts. The intention is for this model to be potentially serializable for users
that need that. Thus, the expressions used in these data structures *MAY* use CLJC functions/code, or may represent
such elements a strings or other (quoted) EDN. The ExecutionModel is responsible for this part of the interpretation.

The overall data model is represented as a map. The DataModel implementation MAY choose scope and resolution
rules. Location expressions are interpreted by the DataModel, but it is recommended they be keywords or vectors
of keywords.

NOTE: The SCXML standard defines a number of elements (if, else, elseif, foreach, log) for abstract
executable content. In cases where you want to transform an SCXML document to this library you should note that we
treat those XML nodes as content that can be translated ON DOCUMENT READ into the code form used by this library.

Helper functions related to the environment that can be used in a lambda execution environment on
`env`.

A queue that uses core.async to enable support for delayed events and also provides a `run-event-loop!` mechanism
for automatically processing events as they arrive (optional). You may, of course, send the queue the
`evts/cancel-event` to exit your machine (without reaching the final state) to cause the `run-event-loop!` to
exit.

This queue can support any number of running statecharts via their session-ids. `send!` will reject any request that
is missing a target that defines the target session-id. Just use the same instance as the event queue for every
chart.

An event queue that does NOT process event delays via any kind of notification system. Delayed events will
be queued, and will be kept invisible until you ask for an event AFTER the timout of the event has occured.
This means you must manually poll this queue.

This queue DOES support any number of sessions, and maintains separate tracking for each.

This queue DOES NOT support communication with any other kind of system. Only other statecharts with session ids.

There is a helper `(next-event-time session-id q)` that will tell you when the next delayed event will be visible
(as an inst) for a given session id.

This allows you to implement your delivery mechanism in concert with your overall system.

The `process-next-event!` of this implementation processes all available events in a loop and then returns.

See https://www.w3.org/TR/scxml/#events.

Note that there are built-in errors and events https://www.w3.org/TR/scxml/#errorsAndEvents.

An execution model that expects expressions a conditions to be CLJ(C)
expressions or functions. It integrates with the data model so that return values
of scripts/expressions can return updates for the data model. It also requires the event queue
so it can send error events back to the machine if the expression has an error.

Support for invoking futures (CLJ only) from statecharts. This support can be added by
adding it to the env's `::sc/invocation-processors`. An invoke element can specify it wants to
run a function in a future specifying the type as :future.

The `src` attribute of the `invoke` element must be a lambda that takes one argument (the
params of the invocation) and returns a map, which will be sent back to the invoking machine
as the data of a `:done.invoke.invokeid` event.

If the invocation is cancelled (the parent state is left), then future-cancel will be called on the future.

Support for invoking other statecharts. This support can be added by adding it to the
env's `::sc/invocation-processors`. An invoke element can specify it wants to
run another statechart by specifying the type as :statechart, ::sc/chart, or the official w3 URL for scxml.

The `src` attribute of the `invoke` element must be the name of a machine that is in the
statechart registry (in env as ::sc/statechart-registry).

Protocols for the various pluggable bits of this library:

Processor - A state machine processing algorithm. See com.fuclrologic.statecharts.algorithms.
EventQueue - An external event queue for cross (and loopback) communication of machines and external services.
DataModel - A model for saving/fetching data that can be directly manipulated by a state machine.
ExecutionModel - A component that implements the interpretation of runnable code in the machine.
InvocationProcessor - A component that knows how to invoke a specific kind of thing.
StatechartRegistry - A component that can register/retrieve statechart definitions by their name.
WorkingMemoryStore - A component that can save/restore the working memory of a session.

Many methods in the namespace take an `env`. This map will contain keys for the above.

The data model requires a *processing* env, which is the same as above, but also includes a volatile
holding the working memory, context information, and the full statechart definition (e.g. from the
registry).

See `com.fulcrologic.statecharts.specs`.

The `env` is allowed to contain any number of user-defined (namespaced) keys.

A statechart registry that keeps track of the statecharts in an atom.

Functions that set up the simplest version of a state chart that uses the v20150901
implementation (version), a working memory data model,
CLJC execution support, and an event queue that requires manual polling.

Utility functions to help with testing state charts.

A working memory store that uses a simple internal atom to track working memory by session id.