HQL core

HQL is a typed functional language for querying and manipulating typed knowledge. The core names no source: documents, relational tables and graph stores all arrive through an extension, and HyperMarkDown is one of them — see hmd-integration. The language is still being designed. This card describes the intended core; the working bootstrap supports only Int, Float, Bool and same-type numeric addition.

The core should stay small: typed values, bindings, ordinary functions, function application and composition through |. Document and semantic types provide the domain vocabulary. Most operations should be functions, with external capabilities supplied by hql/extensions. HQL should develop its own functional syntax, without adopting SQL clauses or Rust-like trait machinery.

Value vocabulary

Family	Types	Role
Documents	Doc, Card, Section, Link	Authored knowledge and its structure
Semantic	Concept, Relation, Proposition, Evidence	Meaning, claims and support
Collections	Set<T>, Seq<T>, List<T>, Map<K, V>	Membership, order, residence and keyed lookup
Ordinary	String, Int, Float, Bool, Date	General computation; each is a Scalar, a leaf of a Data tree

These are the current design names. Generic types are written with angle brackets, Set<T> and Edge<S, T>, everywhere, and square brackets stay value-level: [alice, bob] is a sequence and xs[0] is indexing. Subtyping, generic parameters and progressive refinement are type-system's subject. Precise schemas, declarations, polymorphism, optional/error types and Date operations remain open. This vocabulary does not require each type to be a primitive in the evaluator.

Bindings and values

alice : Doc = [[alice]]

[[alice]] is a doc reference: it names a document in the current namespace and nothing more, and the -> form built from it is the link operator — see link-op. The binding names the referenced document; a filename does not implicitly introduce a variable. Inferred binding is also preferred:

alice = [[alice]]

A document is not yet a card. Card-ness is established by a checked narrowing, never by the reference; see card-type.

An expression returns a typed value. A program returns its last expression; earlier unbound values are discarded. Bindings retain values for later use. Rendering belongs to the host, and printing or saving requires an explicit effect. Constructing an updated Card does not itself persist a document. The spelling of a no-result type, Unit or Void, remains open.

Context values

cards : Set<Card> denotes the cards in the current vault or namespace. It does not imply a traversal order. See hql/collections.

knowledge denotes the semantic knowledge universe composed of concepts, relations, propositions and evidence. It is richer than a collection of cards or a graph. See hql/knowledge.

knowledge
| graph

Pipes are fundamental to composition and querying. pipes describes the execution direction; hql/knowledge records the unresolved distinction between graph projection and presentation.

Design boundaries

The host supplies a typed document model through an extension over the existing HMD parser and resolver. Raw HMD string searching is not the language's foundation, and neither is HMD the foundation: the document vocabulary belongs to the extension that supplies documents. Namespace imports belong in hql/extensions, including optional init.hql.

The design baseline and unresolved choices are collected in hql/design-status. See also hql, hmd-integration and the program-value model.