← Back to catalogue
Research draft

regular expression

vr.tr.regular-expression · INF.MED

Enable an agent to recognise a regular expression, determine its meaning in a specified dialect and execution context, and judge whether it is suitable and safe for an intended text-processing task.

Thing Registry Information and virtual systems

Research draft, second pass

A second pass drafted this model: the structure a model of this thing needs, and what is known about it in the world. The line under this one says how the second half was obtained - researched against sources, or recalled without web access, in which case nothing here was read anywhere and every claim is a lead to verify. Unreviewed either way.

recalled by Codex without web access - no source was read

Researched by: Codex

Purpose and description

Enable an agent to recognise a regular expression, determine its meaning in a specified dialect and execution context, and judge whether it is suitable and safe for an intended text-processing task.

A regular expression is a formal expression denoting a regular language, used in computing to specify text patterns for matching, although many practical dialects add constructs that can describe nonregular languages.

It can be Parse and compile the expression in a declared engine to check syntax and feature support.; Evaluate acceptance, selected spans and captures against labelled examples and boundary cases.; Search or extract text using an explicit operation and capture contract.; Compare candidate revisions for changes in accepted inputs, match selection and capture outputs.; Assess portability across named engines using feature checks and comparative tests.; Run bounded adversarial performance checks and restrict execution when resource requirements remain unresolved..

Distinguishing features

Its pattern text is interpreted using a declared regular-expression dialect; identical characters can instead be literal text when passed to a literal-search operation.

It expresses text constraints using regex syntax, rather than inheriting the wildcard rules of a filename glob.

Its identity as an expression is distinct from the engine that interprets it and from the match records an execution produces.

A regex used for validation requires an explicit whole-input acceptance rule; finding a matching substring alone does not establish that the entire input conforms.

The model covers practical regex dialects as well as classical regular expressions; the label alone does not establish that every supported construct denotes a regular language.

Scope

+ Pattern text, dialect and options needed to interpret the expression

+ Accepted text and match-selection behaviour under specified operations

+ Captures, assertions, character classes and repetition constraints

+ Unicode, case, newline and boundary semantics

+ Evidence of correctness, portability and bounded execution for intended uses

- Regex engine implementation and deployment lifecycle

- Replacement templates and downstream text transformations

- Input datasets, documents and their content governance

- General-purpose parsers and complete language grammars

- Host-language string literals, transport encodings and compiled pattern objects as independent artifacts

Characteristics

Pattern body
Exact pattern text after decoding any host-language or transport representation Escaping or normalisation changes can alter the expression before the engine interprets it.
Dialect binding
Dialect specification and target engine/version Syntax validity and matching behaviour depend on the selected interpreter.
Effective matching options
External flags and inline option settings, including their scope and precedence Options can change character comparison, anchors, wildcard behaviour and pattern parsing.
Operation contract
Whole-input match, prefix match, substring search or repeated match enumeration The same expression can produce different acceptance and extraction outcomes under different operations.
Capture contract
Group names or numbers, intended meanings, optionality and repeated-capture expectations Consumers may depend on capture structure even when overall matched text is unchanged.
Empty-match capability
Possible, impossible or unresolved under the declared context Zero-length matches affect iteration, splitting and progress guarantees.
Text interpretation
Byte or Unicode processing, character-unit conventions, case rules, newline rules and normalisation assumptions Visual similarity does not guarantee equivalent matching behaviour.
Observed execution cost
Elapsed milliseconds and peak memory bytes for named input families, sizes and engine configurations Performance evidence must be tied to the conditions under which it was obtained.
Verification status
Untested, tested for declared cases, known counterexample or verified under stated assumptions An agent needs to distinguish intended behaviour from demonstrated behaviour.

Also called

URL match patternPython version 3 regular expressionPRONOM internal signaturePOSIX Extended Regular ExpressionsPOSIX Basic Regular ExpressionsRaku rulesJava regular expressionsPerl regular expression

Where this came from

wikidata · CC0 1.0

Source repository Registry entry point

Drafted structure

Bundle to layer to finding to question, as the second pass will find it: 6 bundles · 11 layers · 16 findings · 26 questions.

Pattern identity and dialect Establish the exact expression and the interpretation rules that give it meaning.

Pattern text without its decoding context, dialect and options is insufficient to reproduce behaviour.

Expression representation

Separate the engine-facing pattern from its surrounding representation.

Engine-facing pattern

Record the exact pattern received by the regex engine and identify any delimiters or escaping that belong to its container.

  1. What exact pattern text reaches the engine after string-literal, configuration or transport decoding? definition
  2. Which surrounding delimiters and escape sequences belong to the host representation rather than the expression? boundary

Interpretation binding

Identify syntax rules, feature support and effective options.

Dialect and option resolution

Bind the expression to a dialect and target engine, accounting for external flags and scoped inline settings.

  1. Which dialect reference and engine/version define the intended interpretation? provenance
  2. What options are effective in each part of the pattern after inline and external settings are resolved? definition
Acceptance and match selection Describe what qualifies as a match and which qualifying result an operation selects.

Validation, searching and repeated matching require different contracts even when they share a pattern.

Acceptance boundaries

Connect the intended text constraint to input coverage and assertion behaviour.

Input coverage contract

Specify whether acceptance concerns the entire input, a prefix or a substring, including the effects of anchors and surrounding context.

  1. Must the entire input satisfy the expression, or is a matching prefix or substring sufficient? definition
  2. Can final newlines, line-oriented anchors or lookaround context cause acceptance to differ from the intended boundary rule? boundary

Selection and iteration

Resolve competing matches and the progression of repeated searches.

Selected match sequence

Record how engine selection rules, alternatives and repetition interact with overlap and zero-length match handling.

  1. When several matches are possible, which span does the target engine select under this operation? definition
  2. How should repeated matching advance after a zero-length match, and are overlapping matches required? action
Captures and pattern capabilities Make extraction outputs and dialect-specific constructs explicit.

Matching the expected span does not guarantee correct capture outputs or support in another engine.

Capture interface

Treat capture groups as an observable interface consumed by downstream actions.

Capture output contract

Describe group identity and meaning, including unmatched optional groups, empty captures and groups inside repetition.

  1. Which named or numbered groups are consumed, and what text is each intended to return? definition
  2. How must consumers distinguish an unmatched group, an empty capture and the outputs of a repeated group? boundary

Construct dependencies

Identify pattern features that constrain interpretation, analysis and migration.

Feature and portability profile

Record dependencies such as backreferences, lookaround, recursion or engine-specific syntax without assuming that all regex dialects share them.

  1. Which constructs does this expression use that require explicit support checks in a target engine? definition
  2. What accepted-input, span and capture comparisons are required before a translated expression can replace this one? action
Character and boundary semantics Specify how the expression interprets text units, classes and boundaries.

Regex behaviour can change across scripts, encodings and newline conventions while the visible pattern remains identical.

Text units and equivalence

Clarify what counts as a character and which text differences matching ignores.

Unicode and case contract

Record relevant byte, code-unit, code-point or grapheme behaviour and the assumptions governing case comparison and normalisation.

  1. What text units do wildcard matching, repetition and returned offsets use in the target environment? definition
  2. Are case folding and Unicode normalisation required, and which transformations occur before regex evaluation? boundary

Classes and text boundaries

Define shorthand classes, word boundaries and newline-sensitive behaviour.

Class and boundary coverage

Make the intended coverage of digit, word and whitespace classes explicit alongside wildcard and line-boundary rules.

  1. Which characters should digit, word and whitespace classes include, and does the declared dialect match that intention? definition
  2. Which newline sequences and script-specific boundary cases must tests cover for anchors, dots and word-boundary assertions? measurement
Correctness and execution suitability Assess whether the expression fulfils its intended task within acceptable resource limits.

A syntactically valid regex may accept unintended inputs, expose unstable captures or consume excessive resources.

Behavioural evidence

Connect intended requirements to examples, counterexamples and revision checks.

Acceptance and extraction tests

Maintain labelled cases with expected acceptance, selected spans and captures, including cases close to the intended boundary.

  1. Which independently stated requirement determines the expected result for each positive and negative example? provenance
  2. Do tests cover empty input, near misses, unexpected prefixes or suffixes and every capture consumed downstream? measurement

Resource bounds and input trust

Evaluate compilation and matching costs in relation to pattern and input control.

Bounded execution contract

Tie execution permission to measured costs, input-size assumptions, engine guarantees and available interruption controls.

  1. Who controls the pattern and input, and what compilation and matching costs occur as adversarial near-miss inputs grow? measurement
  2. What input limits, timeouts, engine restrictions or pattern revisions are required before this expression may run in its intended context? action
Evidence and external alignment What the world already says about this thing, gathered so the model can be checked against it.

A model that cannot be lined up against existing standards, identifiers and practice cannot be adopted by anyone who already uses them.

Reported evidence

Findings from the breadth pass, kept separate from the structural claims.

Check these first

Recalled without web access and unsourced; every item is a lead to verify.

  • This describes the computing and formal-language sense; no narrower sense was supplied.
  • Practical dialects differ substantially: backreferences can exceed classical regular-language expressiveness, and not all engines support them.
  • Exact syntax, Unicode behavior, resource limits, and performance guarantees require checking the chosen implementation and version.
  1. Which of these check these first hold for the sense of regular expression this model covers, and on what evidence? provenance

Kinds and varieties

Recalled without web access and unsourced; every item is a lead to verify.

  • Classical formal-language regular expressions
  • POSIX basic regular expressions (BRE)
  • POSIX extended regular expressions (ERE)
  • Perl-compatible regular expressions
  • ECMAScript regular expressions
  1. Which of these kinds and varieties hold for the sense of regular expression this model covers, and on what evidence? provenance

Standards and regulation

Recalled without web access and unsourced; every item is a lead to verify.

  • IEEE Std 1003.1 (POSIX), issued by IEEE, specifies basic and extended regular-expression syntax and matching behavior.
  • ECMA-262, issued by Ecma International, specifies ECMAScript regular expressions.
  • Unicode Technical Standard #18, Unicode Regular Expressions, issued by the Unicode Consortium, specifies levels of Unicode support for regular-expression implementations.
  1. Which of these standards and regulation hold for the sense of regular expression this model covers, and on what evidence? provenance

Real-world use

Recalled without web access and unsourced; every item is a lead to verify.

  • Searching and replacing text in editors and command-line tools.
  • Checking whether input conforms to a specified textual format.
  • Extracting fields from logs and other text.
  • Specifying token patterns for lexical analysis.
  • Filtering records or routing requests according to textual patterns.
  1. Which of these real-world use hold for the sense of regular expression this model covers, and on what evidence? provenance

Failure modes and hazards

Recalled without web access and unsourced; every item is a lead to verify.

  • Some backtracking engines take extremely long on certain pattern-and-input combinations, enabling regular-expression denial of service.
  • Unanchored matching or incorrect grouping can accept unintended input or reject valid input.
  • Dialect differences in syntax, match selection, and supported features can change results when patterns are moved between implementations.
  • Unicode, locale, case-folding, and character-boundary assumptions can produce unexpected matches.
  • Incorrect escaping across programming-language strings and regular-expression syntax can alter a pattern; interpolating untrusted text can introduce unintended pattern operations.
  1. Which of these failure modes and hazards hold for the sense of regular expression this model covers, and on what evidence? provenance

Neighbouring kinds and how to tell them apart

Recalled without web access and unsourced; every item is a lead to verify.

  • regular language - A regular language is a set of strings; a classical regular expression is one way to describe that set.
  • finite automaton - A finite automaton recognizes strings through states and transitions; classical regular expressions describe the same class of languages through expression syntax.
  • glob pattern - A glob is a wildcard pattern commonly used for filenames, with syntax and matching rules distinct from regular expressions.
  • context-free grammar - A context-free grammar can describe arbitrary recursive nesting, which classical regular expressions cannot express.
  • regular-expression engine - The engine executes matching operations; the regular expression is the pattern supplied to it.
  1. Which of these neighbouring kinds and how to tell them apart hold for the sense of regular expression this model covers, and on what evidence? provenance

What the second pass must settle

  • Should the registry entry explicitly encompass practical regex constructs beyond classical regular-language expressions, or record that distinction as a required subtype?
  • When should two patterns count as the same expression: exact pattern-and-option identity, equal accepted languages, or equal observable spans and captures under a declared operation?
  • Which dialect specifications and engine versions should anchor the first researched publication and its portability claims?
  • Which Unicode, locale and newline dependencies must be recorded directly versus inherited from an execution-environment model?
  • What evidence threshold should permit an agent to classify a regex as suitable for untrusted inputs under a particular engine and resource budget?
Draft as JSON