The Delightql Runtime¶

The delightql runtime is a set of stateful data and contracts that anyone running a query or script may depend upon.

The delightql runtime guarantees

the existence of certain namespaces
special namespaces for CLI, REPL and library usages
special rules for namespace removal and addition
special namespaces deemed auto-enlisted
the existence of certain entities: rules, functions, sigma predicates, etc.
the existence of certain directives

The runtime namespacing mechanism is introspectable as tables by delightql itself. It also doubles as a code module system and data import mechanism.

This blend of introspection and user-driven namespacing has a precedent in images, a style of always-on programming promulgated by Smalltalk.

Namespace Contracts¶

Built-in Namespaces¶

Delightql provides the following namespaces:

main – where data is mounted when a database is provided at start of process
home – where the REPL’s definitions (.ddl input, inline ddl) are written
std – no entities, just a container for other namespaces
std::prelude – auto-enlisted; the directives and core pseudo-predicates
std::string – string functions
std::constants – named constants such as nl and tab
std::predicates – for like and between
std::help – operators(*), the operator sigils as a relation
std::info – tables(*), the tables visible in the session
std::json, std::math, std::reshape – JSON, aggregate and reshaping (pivot) helpers

std::(*) lists the std namespaces.

While introspectable system tables may be seen and used ( located at all namespaces with a sys prefix) they are not to be depended upon.

This is a hard choice to allow the slow adoption of guranteed introspection and metadata predicates into std while their lower-level and version-based siblings at sys may be churned as dictated by functionality and refactoring.

Delightql is already exceptionally well introspectable, but has not yet decided its public facing contract.

To repeat: all namespaces and entities prefixed by sys do not guarantee stability to a programmer over version changes.

Namespace metadata¶

Namespace catalog functor¶

Every namespace may be called directly:

namespace::subnamespace::(*)

Auto-enlist namespaces¶

Special Protected Namespaces¶

A programmer has wide latitude to create their own tree of namespaces anywhere in the image inclusive of entities within those namespaces.

Delightql sets aside the following namespaces as protected classes:

std-prefixed namespaces may not receive new entities nor add or drop namespaces
sys-prefixed namespaces may not receive new entities nor add or drop namespaces

REPL vs CLI vs CORE¶

System Tables – A Tour¶

All namespaces and entities prefixed by sys do not guarantee stability to a programmer over version changes.

Nevertheless, the current version of delightql has many candidates for promotion to std that there might come a time when

Information Schema Namespaces¶

The following namespaces contain entities that allow introspection of what entities are knowable at runtime. These namespaces contain multiple table or view entities that are created, modified or deleted whenever a programmer runs consult!, mount!, etc.

sys::ns
sys::cartridges
sys::entities
sys::entities::ho
sys::entities::interior