On this page:
2.1 Morphology
2.2 Ideographic Morphological System
2.3 Terminology
2.3.1 Morphological Structure
2.3.2 Ideographic Morphology
2.3.3 Ideograph
2.3.4 Semantic Ideograph
2.3.5 Semantic Implication
2.3.6 Naming Rule
2.3.7 Programmatic Meaning
2.3.8 Conceptual Meaning
2.3.9 Type Prefix
2.3.10 Default Type Context
2.3.11 Component
2.3.12 Composition
2.3.13 Semantic Modifier
2.3.14 Semantic Derivation
2.3.15 Structural Modifier
2.3.16 Position Operator
2.3.17 Extent Operator
2.3.18 Word-position Operator
2.3.19 Rotation Operator
2.3.20 General Type
2.3.21 Minor Type
2.3.22 Minor-type Ideograph
2.3.23 Cardinality
2.3.24 Cardinality Restriction
2.3.25 Output Representation
2.3.26 Summary
2.4 Document Verbs
2.5 core ideographs
9.3.0.10

2 Concepts🔗ℹ

Ming’s ideograph system is not merely a system for naming programming keywords with Chineseoid characters. It establishes an ideographic morphology in which programming concepts, semantic relationships, and structural constraints are expressed through the composition, derivation, and modification of ideographs.

This morphological perspective is fundamental to understanding how Ming’s vocabulary is constructed and how relationships among programming concepts are represented. The terminology used to describe these mechanisms is formally introduced in Terminology.

2.1 Morphology🔗ℹ

In linguistics, morphology concerns the internal structure of words and the ways in which meaningful units combine to form new words or related forms. A word may consist of a root together with prefixes, suffixes, infixes, or other morphological elements, where each element contributes systematically to the meaning or grammatical behavior of the resulting word.

Ming applies a similar principle to programming concepts. An ideograph is therefore not necessarily an indivisible name. It may participate in semantic derivation, structural modification, and composition, so that a resulting ideograph retains a systematic relationship with the concepts from which it is formed.

This internal organization of an ideograph is referred to as its Morphological Structure.

For example, 弓 represents the concept of index. From this concept, further ideographs can be constructed:

  • 弔, derived from 弓 with 丨, represents indexed reference.

  • 𢎨, derived from 弔 with 丿, represents a related form of indexed reference using human-oriented, one-based indexing.

  • 阝 represents a serial-subset relationship.

  • 􏴗, derived from 阝 with 丶, preserves that relationship while modifying its range semantics.

The resulting ideographs are therefore not arbitrary names. Their forms make relationships between programming concepts visible.

The same morphological principle also operates when different kinds of ideographic elements participate in the formation of a procedure name. Some elements primarily contribute an independently meaningful programming concept, while others primarily modify an existing concept, specify structural information, or impose constraints on the procedure represented by the resulting name.

These different roles include:

  • Semantic Ideograph, which provides an independently meaningful programming concept and may serve as a semantic root.

  • Semantic Modifier, which derives a related meaning by modifying some semantic dimension of an existing ideograph.

  • Structural Modifier, which contributes information about the structural formation or positional organization of an ideograph.

  • Composition, through which distinct contributions are combined into a new ideograph or concept.

  • Naming Rule, through which an ideographic component explicitly constrains properties of a procedure through its occurrence or composition within a procedure name.

  • Minor Type, through which more fine-grained distinctions among data structures and values can be represented.

These terms describe different roles that components may play within the same morphological system. Their precise definitions and relationships are given in Terminology.

For this reason, many Ming ideographs should be understood as derived forms rather than as independently invented symbols. Once a semantic relationship has been established, new concepts can be constructed by systematically applying existing semantic or structural elements.

For example,

亻 + 弔 → 伄

does not merely assign a new Chineseoid character to another procedure. 亻 contributes an explicit Naming Rule concerning the relationship between input and output, while 弔 contributes the semantic concept of indexed reference. Their composition therefore produces an operation whose meaning and interface constraints arise from both components.

Likewise,

又LB + 㐅 → 􏿴

expresses the morphological construction of a list, while

􏿴 + 句 → 􏴷

further specifies a list whose elements are strings.

The resulting concepts therefore form a derivational network rather than a flat collection of names.

2.2 Ideographic Morphological System🔗ℹ

This perspective leads to an important characteristic of Ming: its ideographs are not a collection of isolated glyphs created one by one. They belong to a recursive and extensible system in which established semantic concepts, modifiers, structural elements, and Naming Rules can participate in further formations.

We call this overall system Ideographic Morphology.

Once an ideographic unit or relationship has been established, it can participate in further formations. Consequently, Ming’s vocabulary can grow by deriving new concepts from existing ones while preserving explicit relationships between them.

This makes the morphology of Ming fundamentally extensible. A newly constructed ideograph does not merely introduce another name into the vocabulary; it may also introduce a new node and new relationships into the network of programming concepts.

In this sense, Ming’s ideograph system is closer to a morphological grammar for programming concepts than to a conventional naming scheme.

The purpose is not simply to make programming syntax look Chinese. It is to make the internal relationships among programming concepts visible in their names and forms, while allowing those relationships to participate in further semantic and structural composition.

Ming’s ideograph system is not “using Chinese characters to name keywords”; it is establishing an ideographic morphology.

This principle underlies the terminology, morphology, and naming rules described throughout the Ming language.

2.3 Terminology🔗ℹ

Ming’s ideograph system is not merely a system for naming programming keywords with Chinese characters. It establishes an ideographic morphological system for programming semantics.

The ideographs of Ming therefore should not be understood as a collection of independently invented symbols. They form a compositional and derivational system in which individual semantic units, modifiers, structural elements, and naming rules can be combined to construct increasingly specific programming concepts and procedural interfaces.

This morphological system distinguishes different kinds of meaning and different roles played by ideographic components.

                   Ming

                    │

                    ▼

      ideographic composition

             ↓ semantic composition

                    │

                    ▼

         conceptual explanation

                    │

                    ▼

         Ideographic Morphology

                    │

       ┌────────────┼─────────────┐

       ▼            ▼             ▼

Semantic        Naming        Composition

Ideograph        Rule          / Derivation

       │            │

       ▼            ▼

Conceptual     Programmatic

Meaning          Meaning

At the most fundamental level, Ming distinguishes between conceptual meaning and programmatic meaning.

Conceptual meaning represents what a programming concept means in itself. It is primarily expressed by Semantic Ideographs, which may exist independently of any particular procedure and may be used to describe concepts, data structures, Minor Types, or other semantic entities.

Programmatic meaning, in contrast, expresses properties and relationships that concern a program or procedure itself, such as input and output types, parameter kinds, cardinality, or structural relationships. It is primarily encoded through Naming Rules, whose purpose is to impose such constraints through the morphology of a procedure name.

This distinction is not a distinction between meaningful and meaningless ideographs. Both Semantic Ideographs and Naming Rules carry meaning; they differ in the kind of meaning they primarily express.

A Semantic Ideograph primarily answers:

What concept does this represent?

A Naming Rule primarily answers:

What must a procedure represented by this name be like?

Ming's

Ideographic Morphology

│

├── Semantic Ideograph

│      │

│      ├── Conceptual Meaning

│      │

│      └── Semantic Implication

│

├── Semantic Modifier

│      │

│      └── Semantic Derivation

│

├── Structural Modifier

│

├── Composition

│

└── Naming Rule

       │

       └── Programmatic Meaning

              │

              ├── Input constraints

              ├── Output constraints

              ├── Type constraints

              ├── Cardinality

              └── Structural relationships

Other ideographic components operate between and around these two roles. Semantic Modifiers derive related meanings from existing concepts, Structural Modifiers describe or alter the morphological structure of an ideograph, and Composition Ideograph combines distinct semantic or structural contributions into a new form.

The resulting system can therefore be viewed as a morphological grammar for programming concepts: existing concepts and rules become building blocks from which new, systematically related concepts can be derived.

2.3.1 Morphological Structure🔗ℹ

The Morphological Structure of an ideograph is the organization of its constituent semantic, modifying, structural, and naming-rule components.

Morphological Structure determines how the components of an ideograph are interpreted in relation to one another.

This makes an ideograph more analogous to a morphologically constructed word than to an arbitrary identifier.

For example:

伄 = 亻 + 弔

contains both a Naming Rule and a Semantic Ideograph. Its meaning is therefore obtained not simply by looking up 伄 as an atomic symbol, but by interpreting the relationship between its components.

2.3.2 Ideographic Morphology🔗ℹ

Ideographic Morphology is the overall system by which Ming constructs programming meanings through the composition, derivation, modification, and structural organization of ideographs.

It includes:

Ming’s ideographic morphology is therefore not merely a visual notation system. It is a mechanism for systematically constructing and exposing relationships among programming concepts.

2.3.3 Ideograph🔗ℹ

Ideograph is a character or ideographic unit used in Ming to represent a semantic, programmatic, or morphological element.

An ideograph may represent an independently meaningful programming concept, explicitly constrain the interpretation of a procedure name, modify an existing concept, or specify the structural organization of an ideographic composition.

According to their primary role, Ming ideographs include:

These roles are functional rather than mutually exclusive in every possible context: an ideographic component may participate in different morphological relationships depending on how it is used.

Ideograph

│

┌──────────────────┼──────────────────┐

│                  │                  │

↓                  ↓                  ↓

Semantic          Naming Rule       Structural /

Ideograph           Ideograph         Morphology

│                  │                  │

│                  │                  ├── Position

│                  │                  ├── Extent

│                  │                  ├── Word position

│                  │                  └── Rotation

│                  │

│                  ├── Type relation

│                  ├── Input constraint

│                  ├── Output constraint

│                  └── Cardinality constraint

│

├── Data concept

├── Operation concept

├── Representation concept

└── Structural concept

 

 

Ideograph

│

├───┐

│   ├── Semantic Ideograph

│   │

│   ├── General-Type Ideograph / Minor-Type Ideograph

│   │

│   └── Naming-Rule Ideograph

│

├── Semantic Modifier

│

└── Structural Modifier

 

 

Ideograph

│

├── structurally-modified-by → Structural Modifier

│

├── semantically-modified-by → Semantic Modifier

│

└── composed-with → Composition Ideograph

2.3.4 Semantic Ideograph🔗ℹ

A Semantic Ideograph is an ideograph whose primary function is to represent an independently meaningful programming concept.

A Semantic Ideograph is not inherently tied to a particular procedure name. It may be used to express a concept in a variety of contexts, including the description of data structures, Minor Types, or other semantic entities.

For example:

Semantic Ideograph in Ming

Corresponding English concept in Racket

弓

index

弔

indexed reference

彐

find

毌

append

並

multiple values

双

pair

􏿴

list

􏿰

hash

㐅

null

句

string

?

predicate

!

modification of the original value

When a Semantic Ideograph participates in a procedure name, its semantic meaning may naturally imply properties of the procedure. These are Semantic Implications, rather than necessarily being Naming Rules.

For example, the meaning of ? as a predicate conventionally implies a Boolean result, while the meaning of ! as an operation that modifies the original value conventionally implies a void result.

2.3.5 Semantic Implication🔗ℹ

Semantic Implication is a type, structural, or behavioral property that can be inferred from the semantic meaning of an ideograph, rather than being explicitly declared as a naming rule.

A Semantic Implication is a property of a procedure, operation, or data relationship that follows naturally from the meaning of a Semantic Ideograph.

A Semantic Implication is not necessarily stated as an explicit naming rule. Rather, it arises from the semantic interpretation of the concept represented by the ideograph.

For example, the concept represented by ? is predicate. In the context of a procedure, this naturally implies that its result is Boolean.

Likewise, ! represents modification of the original value. The conventional consequence is that the procedure produces a void result.

Semantic Implications may therefore provide interface information without being the primary purpose of the ideograph.

e.g. 弔 only means indexed reference, but when it is used as procedure 弔, we have:

input Rule Rule 1 = list

input 2 = number

output = element

those input and output types are derived from its semantic concept. The way how we derive those types are called semantic implication.

伄:

亻→ explicit rule

弔 → semantic implication

2.3.6 Naming Rule🔗ℹ

A Naming Rule is a rule encoded by an ideographic component that explicitly constrains or determines the interface or operational structure of a procedure through its position or composition within a procedure name.

A Naming Rule may specify properties such as:

  • the type or structure of an input;

  • the type or structure of an output;

  • relationships between inputs and outputs;

  • parameter kinds;

  • cardinality;

  • or other structural relationships of an operation.

Unlike a Semantic Ideograph, a Naming Rule does not primarily exist to represent an independently referential programming concept. Its meaning is primarily morphological and programmatic: it specifies how a procedure bearing the corresponding name is to be understood or constrained.

For example:

  • ^ specifies that the input is a list.

  • 亻 specifies a derived-set relationship between input and output.

  • 阝 specifies a serial-subset relationship.

  • 入 specifies that an input parameter is a function.

A Naming Rule may nevertheless carry meaningful information. Its distinction from a Semantic Ideograph is not that it is meaningless, but that its meaning primarily concerns the formation and interpretation of a procedure rather than an independently existing concept.

亻

Role:

naming-rule

Rule:

output data has the same type as input data;

output elements are derived from / belong to the input data.

Default type:

list

Type override:

determined by a type-prefix ideograph

For example, 伄 = 亻 + 弔. Among them:

亻 → explicit constraint

弔 → semantic concept

2.3.7 Programmatic Meaning🔗ℹ

Programmatic Meaning is meaning concerning the properties, relationships, and behavior of a program or procedure, including its data, types, inputs, outputs, parameters, cardinality, and structural relationships.

Naming Rules primarily express Programmatic Meaning.

This should be distinguished from the Conceptual Meaning expressed by Semantic Ideographs.

Thus:

Semantic Ideograph → Conceptual Meaning

Naming Rule → Programmatic Meaning

The distinction concerns the primary role of the meaning rather than whether an ideograph possesses meaning at all.

2.3.8 Conceptual Meaning🔗ℹ

Conceptual Meaning is the meaning of an independently recognizable concept represented by an ideograph.

Conceptual Meaning may exist independently of any particular procedure or naming context. It can therefore be used to describe programming concepts, data structures, Minor Types, or other semantic entities.

For example, 弓 can express the concept of index independently of any particular procedure.

2.3.9 Type Prefix🔗ℹ

Type Prefix is an ideograph placed before a procedure name as a word-level prefix to determine or override the data type referred to by a naming rule.

e.g. where 􏿴(list) is put first in 􏿴伄, and 􏿲(vector) in 􏿲伄, are both type prefix.(Since 伄 specifies T → T, 􏿴 and 􏿲 as the type prefixes here have made the T be list and vector.)

2.3.10 Default Type Context🔗ℹ

Default Type Context is ahe implicit data type supplied when a naming rule is used without an explicit type prefix.

e.g. since 亻’s default type is 􏿴(list), 伄 can be seen as the abbreviated form of 􏿴伄.

2.3.11 Component🔗ℹ

Component is an ideograph or morphological unit used to construct another ideograph. e.g. Since 伄 = 亻 + 弔, both 亻 and 弔 are components of 伄.

2.3.12 Composition🔗ℹ

Composition is the formation of an ideograph or programming concept by combining two or more ideographic components whose semantic or structural contributions are jointly interpreted.

Composition differs from Semantic Derivation in that the constituent components may contribute distinct concepts or rules rather than one component simply modifying another.

Examples include:

component₁ + component₂ + ... + componentₙ

│

↓

Composition

 

亻 + 弔 → 伄

亻 + 􏴫 → 􏳋

􏴺 + 並 → 􏳥

毌 + 􏿴BR → 􏿝

又LB + 㐅 → 􏿴

The resulting form derives its interpretation from the systematic interaction of its components.

2.3.13 Semantic Modifier🔗ℹ

A Semantic Modifier is an ideographic component that modifies an existing semantic concept while preserving a systematic relationship with that concept.

A Semantic Modifier may modify dimensions such as semantic scope, extent, cardinality, range, indexing convention, representation, or perspective.

For example:

* expresses strengthening. ~ expresses weakening. 丨, 丿, and 丶 act as small semantic modifiers that derive closely related meanings from existing ideographs.

When a Semantic Modifier is applied to an ideograph, the resulting form constitutes a Semantic Derivation.

阝 → 􏴗, where 丶 acts as a semantic modifier of 阝.

阝

↓

serial subset

 

阝 + 丶

↓

􏴗

↓

serial Rule subset with a modified range

弔 → 𢎨, where 丿 acts as a semantic modifier of 弔.

弔

↓

indexed reference

 

弔 + 丿

↓

𢎨

↓

human Rule-oriented indexed reference

𰁦 → 攸, where 丨 acts as a semantic modifier(more specificity called cardinality restriction) of 𰁦.

2.3.14 Semantic Derivation🔗ℹ

Semantic Derivation is the derivation of an ideograph from another ideograph by applying one or more semantic modifiers, resulting in a new ideograph whose meaning remains systematically related to the source ideograph.

Examples include:

弔 + 丿 → 𢎨

弔 + 一 → 􏴧

阝 + 丶 → 􏴗

𰁦 + 丨 → 攸

 

Base Ideograph

+

Semantic Modifier

↓

Derived Ideograph

 

弓

│

semantic derivation

│

└── 丨

↓

弔

│

└── 丿

↓

𢎨

2.3.15 Structural Modifier🔗ℹ

A Structural Modifier is an ideographic component whose primary function is to specify or modify the structural or positional organization of ideographic components rather than their conceptual meaning.

Structural Modifiers describe how an ideograph is formed, where a component occurs, or how components relate spatially or morphologically.

Examples include:

 L R T B  LB BR BL  PFX SFX IFX  RTT1 RTT2 RTT3

These elements belong to the morphology of an ideograph rather than directly expressing an independent programming concept.

又

│

structural

│

又LB

│

├─────────┐

│         │

↓         ↓

􏿴        􏿫

↑         ↑

㐅         又

2.3.16 Position Operator🔗ℹ

Position Operator: e.g.  L R B T

2.3.17 Extent Operator🔗ℹ

Extent Operator: e.g.  LB BR BL

2.3.18 Word-position Operator🔗ℹ

Word-position Operator: e.g.  PFX SFX IFX

2.3.19 Rotation Operator🔗ℹ

Rotation Operator: e.g.  RTT1 RTT2 RTT3

2.3.20 General Type🔗ℹ

General Type is all the traditional types of what we call in Racket. e.g.  􏿴 句 􏿰 勺

2.3.21 Minor Type🔗ℹ

A Minor Type is a fine-grained classification of a data structure or value based on structural or semantic properties that are more specific than conventional broad programming-language types.

Ming uses its ideographic morphology to expose distinctions that would often remain implicit within conventional types.

For example, the distinction among:

  • pair;

  • list;

  • non-empty list;

  • association list;

  • list of lists;

  • list of strings;

can be represented through systematically related ideographs rather than being treated merely as unrelated names.  􏿫 􏿳 􏴳 􏴷 are all minor types of general type of 􏿴.

Minor Types therefore represent one of the consequences of Ming’s semantic and morphological system: the naming system can express distinctions in data structure that conventional type categories often leave implicit.

2.3.22 Minor-type Ideograph🔗ℹ

Minor-type Ideograph is a refined data-structure type distinguished by structural properties, element types, termination forms, nesting, cardinality, or other semantic invariants beyond a general data type.

e.g.  􏿴 􏿫 􏿳 􏴳 􏴷.

2.3.23 Cardinality🔗ℹ

Cardinality is the number or multiplicity of data units represented or produced by an ideograph. e.g.

二 → exactly 2

三 → 3 / multiple in designated contexts

􏴫 → two sections

􏴺 → multiple sections

􏴫

semantic:

sectionalization

cardinality:

2

2.3.24 Cardinality Restriction🔗ℹ

Cardinality Restriction is one kind of Semantic Modifier and specifically changes the base ideograph to constrains itts semantic parameterization. e.g. 丨 in 攸.

2.3.25 Output Representation🔗ℹ

Output Representation is the form in which multiple output data are represented or returned. e.g.

􏳥L:

sectionalization

+

output-representation = values

􏳋:

sectionalization

+

output-representation = list(default type context)

2.3.26 Summary🔗ℹ

The terminology can be summarized as follows:

Ideographic Morphology

│

├── Semantic Ideograph

│     └── Conceptual Meaning

│           └── Semantic Implication

│

├── Semantic Modifier

│     └── Semantic Derivation

│

├── Structural Modifier

│

├── Composition

│

└── Naming Rule

      └── Programmatic Meaning

            └── procedure/interface constraints

The central principle is that Ming does not merely assign Chinese characters to pre-existing programming-language concepts. It uses the morphological properties of ideographs to construct, relate, and constrain programming meanings.

In this sense, Ming’s ideograph system is an ideographic morphological system for programming semantics.

2.4 Document Verbs🔗ℹ

Ming uses a small set of verbs with specific meanings when describing the relationships among ideographs, their components, and the properties they express. These verbs should be used consistently throughout the documentation.

  • Because of Composition, we use the verb compose to describe the formation of an ideograph from its components. For example, 􏿝 is composed of 毌 and 􏿴BR, and 􏳋 is composed of 亻 and 􏴫.

  • Because of Composition, we use contribute to describe the role played by a component in the meaning or constraints of the resulting ideograph. For example, 亻 contributes a Naming Rule concerning the relationship between input and output in 伄, while 弔 contributes the semantic concept of indexed reference.

  • Because of Naming Rule, we use the verb specify to describe an explicit constraint imposed by an ideographic component. For example, 亻 specifies that the output has the same type as the input.

  • Because of Semantic Ideograph and Semantic Implication, we use the verb imply to describe a property that follows from the semantic meaning of an ideograph rather than being explicitly specified as a Naming Rule. For example, 弓 implies that the corresponding index is a number.

  • Because of Semantic Ideograph, we use the verb represent when an ideograph directly stands for a programming concept. For example, 弓 represents index, 彐 represents find, and 毌 represents append.

  • Because of Semantic Ideograph, we use the verb express when emphasizing that an ideograph gives explicit semantic expression to a concept or relationship. For example, 并 expresses the concept of multiple values.

  • Because of Semantic Derivation, we use the verb derive to describe the relationship between an existing ideograph and an ideograph constructed from it by modification. For example, 𢎨 is derived from 弔 by adding 丿, and 􏴗 is derived from 阝 by adding 丶.

  • Because of Semantic Modifier, we use the verb modify when an ideographic component changes some semantic dimension of an existing concept. For example, 丿 modifies the indexing convention of 弔.

  • Because of Structural Modifier, we use the verb position when describing the role of a component determined by its structural location, such as L, R, or T. For example, 􏳥 uses 􏳥L to position the corresponding Naming Rule on the right side of the composition.

  • When an ideograph is interpreted according to the combination of its components, we use the verb combine when the emphasis is on the resulting interpretation rather than on the physical formation of the glyph. For example, 亻 and 弔 combine to express an operation that performs indexed reference while satisfying the Naming Rule contributed by 亻.

  • When an ideograph preserves a semantic relationship from one of its components while adding a further distinction, we use preserve to describe the inherited relationship. For example, 􏴗 preserves the serial-subset relation of 阝 while modifying its range.

  • When a Semantic Modifier or other component makes an existing concept more specific, we use refine to describe the resulting specialization. For example, 􏴷 refines the list concept represented by 􏿴 by specifying that its elements are strings.

  • When a component extends an existing concept without replacing its original meaning, we use extend to describe the relationship. For example, 𢎨 extends 弔 with a human-oriented indexing convention.

  • When a procedure name contains an ideograph whose Naming Rule determines a property of the procedure, we use constrain when discussing the resulting procedure interface. For example, the 亻 component constrains the input and output types of 伄 to be the same.

  • When a Semantic Ideograph or its composition gives rise to an unstated property of an operation, we use imply rather than specify. For example, 弔 implies that an index is required as an input and that the referenced value belongs to the indexed input structure.

  • When an ideograph is used as a component of a procedure name, we use occur in or appear in to describe its syntactic presence without making a claim about its semantic role. For example, 亻 occurs in the name 伄.

The distinction among these verbs is intentional:

  • compose describes how an ideograph is formed from components.

  • represent and express describe conceptual meaning.

  • specify describes an explicit Naming Rule.

  • imply describes a property that follows from semantic meaning.

  • derive describes the relationship between a source ideograph and a derived ideograph.

  • modify describes a change introduced by a modifier.

  • preserve describes a relationship inherited from an existing ideograph.

  • refine describes increased semantic or structural specificity.

  • extend describes the addition of a related semantic dimension.

  • constrain describes the effect of a Naming Rule on a procedure interface.

  • contribute describes the role of a component in the resulting composition.

2.5 core ideographs🔗ℹ

Idepgraph

Role

Concept/Rule

Derived from

亻

naming rule

same input/output type; output elements derived from input

semantic borrowing

阝

naming rule

serial subset; output same type, successive subset

borrowed

􏴗

naming rule / modifier

suffix-to-end subset

阝-related

􏴫

semantic + naming rule

sectionalization, exactly 2

段

􏴺

semantic + naming rule

sectionalization, multiple

􏴫 + 一

並

semantic

multiple values

semantic extension of 并列

弓

semantic

index

glyph borrowing

弔

semantic

indexed reference

simplified/derived from 第

𢎨

semantic

human-oriented indexed reference

弔 + 丿

彐

semantic

find

simplified from 寻

毌

semantic

append

historical semantic inheritance

双

semantic / type

pair

又 + 又

㐅

semantic / type

null

derived borrowing

􏿴

minor type

proper list

又LB + 㐅

􏿫

minor type

improper/list* structure

又LB + 又

􏿳

minor type

association list

双RB + 㐅

􏴳

minor type

list of lists

又LB + 􏿴

􏴷

minor type

list of strings

􏿴LB + 句

􏳋

naming rule

same-type sectional output

亻 + 􏴫

􏳥

naming rule / representation

sectional values

􏴺 + 並

􏿰

type/data structure

hash

广 + 双