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 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,
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 |
│ |
│ │ |
│ ├── Conceptual Meaning |
│ │ |
│ └── Semantic Implication |
│ |
│ │ |
│ └── Semantic Derivation |
│ |
│ |
├── Composition |
│ |
└── Naming Rule |
│ |
│ |
├── 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:
and the semantic and programmatic relationships resulting from them.
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:
Semantic Ideographs, which primarily represent conceptual meanings;
Naming-Rule Ideographs, which primarily impose explicit constraints on procedure interfaces or behavior;
Semantic Modifiers, which modify or derive semantic concepts;
Structural Modifiers, which specify or modify the morphological organization of ideographs.
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 |
│ │ |
│ │ |
│ └── Naming-Rule Ideograph |
│ |
│ |
|
|
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.
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.
input Rule Rule 1 = list |
input 2 = number |
output = element |
伄: |
亻→ 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 |
亻 → 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:
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:
│ |
↓ |
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.
阝 |
↓ |
serial subset |
|
阝 + 丶 |
↓ |
|
↓ |
serial Rule subset with a modified range |
弔 |
↓ |
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
2.3.17 Extent Operator
2.3.18 Word-position Operator
2.3.19 Rotation Operator
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.
2.3.23 Cardinality
二 → 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
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 |
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 | 广 + 双 |