Glossary

This document contains words and definitions for terms as they are used in Quest and its documentation. Some terms may be synonymous in other domains. This document is subject to change frequently in the early stages as we learn more about the nature of each feature we add to Quest. However, words already used in documentation are not likely to change unless the collective begins using it in a way different than what is written in this document. In that case, this document should change to reflect actual usage.

Applications language -- An applications language is intended for writing applications with the assumption that the programs will be running in the environment of an operating system. An applications language might rely heavily on the built in libraries and functionality of its underlying operating system. Vellum is first and foremost an applications language to facilitate writing rich, maintainable extensions for Quest.

Cache -- saving the results of work on sources that don't change, such as precompiled headers, generating configuration, and so on.

the word 'cache' is also used with prefixes in certain contexts:

• i-cache: CPU Instruction Cache
• d-cache: CPU Data Cache

In some high performance modules, C++ code can become unidiomatic or even obfuscated for the sake of cache optimization. In such cases, documentation will use i-cache and d-cache to refer to physical cache on a CPU in explaining the rationale for inelegant patterns.

Concatenative programming -- A model of computation defined by composing functions with each other. It is an alternative model to the much better-known Turing machine and Lambda calculus models, with equivalent power. The simplest definition is that it, somewhat like most computers' machine codes, consists of a stack and operations that push and pull from that stack. Though, as a theoretical model, it has a lot of differences with actual machine code, such as not having "main memory". However, a stack is not a necessary part of the concatenative paradigm, and in fact Vellum's concatenative model does without one.

Core -- similar in principle to the kernel of an operating system, Core implements the basic functionality one would expect of a text editor: any datastructures required, undo/redo information, keyboard and mouse event routing, and messaging between extensions. It also manages all threading, giving extensions computer time. Fundamentally, Core is meant to guarantee absolute responsiveness and stability of the editor.

Extension -- an extension is a component written in the extension language that extends the capabilities of the editor. It uses Core's built-in messaging system to communicate with other extensions and plugins.

Freestanding program -- In systems programming parlance, a freestanding program is one designed to run without an operating system on bare metal or perhaps virtualization software. Vellum will not be designed with such a use case in mind.

Input mode -- a mapping of keyboard inputs to editor functions, able to be switched on the fly per-buffer. For example:

• Insert mode: a mode where every letter, number, and punctuation key inserts itself.
• Vim's normal and visual modes: modes where bare keys can execute complex functions.
• Chord modes: after pressing a chord, for example C-x in Emacs emulation mode, a secondary mapping is loaded for all keybindings which use C-x as a prefix.

Notional tuple -- While most concatenative models are defined to operate upon a stack, Vellum Substrate is defined to operate on a tuple, which is similar to, but not quite the same as, a Vellum builtin tuple type, hence why it is a "notional" tuple. At the boundaries between Substrate and structured Vellum code, however, tuple types and notional tuples may be converted between by the language. The notional tuple differs from a stack by being strongly typed, rather than allowing arbitrary pushes and pops. Every expression in Substrate code is defined as a function call which takes the notional tuple as input and produces a new tuple as output.

Overlay -- An overlay is a type of extension or plugin that can change the behavior or editing experience throughout the entire editor. Some overlays behave as a service that can be invoked, like org's org-capture, or potentially a screen reader.

Plugin -- a plugin is a separate binary that uses sockets to communicate with core and other editor components, hence an LSP server or nimsuggest would be considered plugins.

Quest book -- a quest book, or simply book if context allows, is a Quest extension in the form of a Vellum package. Many pages of vellum make a book, many files of Vellum make a Quest book.

Scripting language -- A scripting language is simply a language used for writing scripts. A script is a program intended to automate repetitive tasks that would otherwise be done by a human operator. In this sense, Any language can be used for scripting and be considered a scripting language. In its role as the primary extension language for Quest, Vellum can be used as a scripting language, however, it is designed to handle larger applications than typical scripts.

Structured syntax -- Vellum is actually two languages at once, the "normal" one, immediately familiar to programmers with a procedural background, called "Structured Vellum", named so because it uses high-level syntactical constructs, like braces and "if", that express the structure of the control flow, and the other, "Vellum Substrate", being a lower-level semi-independent concatenative language with almost no structured syntax beyond that required to simply name entities.

Substrate -- Substrate is the name of the concatenative programming model which forms the basis of Vellum's evaluation model, as well as a language for directly expressing programs in that model. Substrate code can be freely intermixed with structured Vellum code. Purely substrate programs can be extremely terse and thus may be suitable for writing complex text transformations on the fly similar to emacs lisp.

Systems language -- A systems programming language is a language intended to make writing freestanding programs possible. Vellum is not intended to be a systems language, but rather an applications language.