Requirement
Plurality belongs in the base language, not in form-builder UI code.
Surface syntax such as:
should mean a nonempty plural value of Email_Address — semantically, one or more Email_Address values.
Likewise, ordinary inflection sugar could support forms such as:
Phone_Number(s)
Part(s)
Child(ren)
The spelling is surface syntax; the important language feature is the cardinality-bearing type underneath.
Semantics
Keep these meanings distinct:
Email_Address exactly one
Email_Address(es) one or more
optional Email_Address zero or one
zero_or_more Email_Address zero or more
For the plural form, the language must know that the collection is nonempty (count ≥ 1). It should not merely lower immediately to an unconstrained generic list and forget that fact.
This is related to #58's compiler-visible constrained domains: collection cardinality is another constraint the compiler should preserve rather than a convention invented by each library.
First dogfood case
isomorphisms/idric-form-builder needs to express a school form field that accepts one or more email addresses:
reply_addresses : Email_Address(es)
A renderer may accept the same value through repeated + Add another controls, comma-separated input, semicolon-separated input, or newline-pasted input. Those are input syntaxes for one plural typed value; they are not different schemas.
Acceptance direction
- one
Email_Address inhabits Email_Address(es);
- two or more addresses inhabit it;
- the empty value does not;
- cardinality information remains visible through the compiler pipeline;
- element validation remains
Email_Address validation;
- consumers such as form-builder can inspect the plural cardinality and choose an appropriate interaction without re-declaring the semantics locally.
Do not solve generic collection design, persistence, networking, or UI policy in this issue. The smallest executable slice is first-class nonempty plurality plus one concrete semantic type.
Requirement
Plurality belongs in the base language, not in form-builder UI code.
Surface syntax such as:
should mean a nonempty plural value of
Email_Address— semantically, one or moreEmail_Addressvalues.Likewise, ordinary inflection sugar could support forms such as:
The spelling is surface syntax; the important language feature is the cardinality-bearing type underneath.
Semantics
Keep these meanings distinct:
For the plural form, the language must know that the collection is nonempty (
count ≥ 1). It should not merely lower immediately to an unconstrained generic list and forget that fact.This is related to #58's compiler-visible constrained domains: collection cardinality is another constraint the compiler should preserve rather than a convention invented by each library.
First dogfood case
isomorphisms/idric-form-builderneeds to express a school form field that accepts one or more email addresses:A renderer may accept the same value through repeated
+ Add anothercontrols, comma-separated input, semicolon-separated input, or newline-pasted input. Those are input syntaxes for one plural typed value; they are not different schemas.Acceptance direction
Email_AddressinhabitsEmail_Address(es);Email_Addressvalidation;Do not solve generic collection design, persistence, networking, or UI policy in this issue. The smallest executable slice is first-class nonempty plurality plus one concrete semantic type.