=pod

=encoding utf8

=head1 NAME

Muldis::D::Core::Types_Catalog -
Muldis D catalog-defining data types

=head1 VERSION

This document is Muldis::D::Core::Types_Catalog version 0.132.0.

=head1 PREFACE

This document is part of the Muldis D language specification, whose root
document is L<Muldis::D>; you should read that root document before
you read this one, which provides subservient details.  Moreover, you
should read the L<Muldis::D::Core> document before this current
document, as that forms its own tree beneath a root document branch.

=head1 DESCRIPTION

These core data types are more special-purpose in nature and are intended
for use in defining or working with the system catalog.

Note that whenever an attribute of one of the nonscalar types isn't
significant, given the context (determined by other attributes of the same
type), and should be ignored, its value is the default for its type.

Note that many of the tuple types might conceptually have C<name>
attributes, but those would actually be provided by any larger types in
which they are embedded, rather than by these types themselves.

I<Note that for every relation type defined in this file, there also exists
a corresponding tuple type in terms of which the relation type is partly
defined; that tuple type is not yet explicitly defined in this file but a
future spec update should change this.>

I<To keep things simpler for now, most constraint definitions for these
types are missing, or just defined informally.>

=head1 TYPE SUMMARY

This section shows all the data types and data type factories described in
this document, which are specific to defining the system catalog, more or
less.  Since there are a number of types with multiple parents, those types
may appear multiple times in the graph; moreover, the graph is displayed in
multiple slices, some of which are different views of the same type
relationships.  See L<Muldis::D::Core::Types/TYPE SUMMARY> for context.

This graph slice shows all of the top-level catalog types, plus some
non-core catalog types for context:

    sys.std.Core.Type.Universal
        sys.std.Core.Type.Cat.List
            sys.std.Core.Type.Cat.Structure
                sys.std.Core.Type.Cat.String
                sys.std.Core.Type.Tuple
                sys.std.Core.Type.Relation
                sys.std.Core.Type.Cat.ScalarWP
                sys.std.Core.Type.External
            sys.std.Core.Type.Cat.Nonstructure
        sys.std.Core.Type.Scalar
            sys.std.Core.Type.Cat.ScalarWP
                sys.std.Core.Type.Cat.DHScalarWP
            sys.std.Core.Type.DHScalar
                sys.std.Core.Type.Int
                sys.std.Core.Type.Cat.String
                sys.std.Core.Type.Cat.DHScalarWP
                sys.std.Core.Type.Cat.OVLScalar

This graph slice shows all of the catalog scalar types:

    sys.std.Core.Type.Universal
        sys.std.Core.Type.Scalar
            sys.std.Core.Type.DHScalar

                # The following are all regular ordered scalar types.

                sys.std.Core.Type.Cat.String
                    sys.std.Core.Type.Cat.BString
                    sys.std.Core.Type.Cat.OString
                    sys.std.Core.Type.Cat.UCPString

                sys.std.Core.Type.Cat.DHScalarWP

                    # The following are all regular ordered scalar types.

                    sys.std.Core.Type.Cat.Name
                    sys.std.Core.Type.Cat.NameChain
                        sys.std.Core.Type.Cat.PNSQNameChain
                            sys.std.Core.Type.Cat.MaterialNC
                                sys.std.Core.Type.Cat.AbsPathMaterialNC
                                    sys.std.Core.Type.Cat.APFunctionNC
                                    sys.std.Core.Type.Cat.APImperativeNC
                                    sys.std.Core.Type.Cat.APTypeNC
                                sys.std.Core.Type.Cat.RelPathMaterialNC
                                    sys.std.Core.Type.Cat.RPFunctionNC
                                    sys.std.Core.Type.Cat.RPImperativeNC
                                    sys.std.Core.Type.Cat.RPTypeNC
                            sys.std.Core.Type.Cat.DataNC
                    sys.std.Core.Type.Cat.Comment
                    sys.std.Core.Type.Cat.Order
                        sys.std.Core.Type.Cat.Order.*

                    # The following are all regular non-ord scalar types.

                    sys.std.Core.Type.Cat.RoundMeth
                        sys.std.Core.Type.Cat.RoundMeth.*
                    sys.std.Core.Type.Cat.RatRoundRule

                    # The following are other singleton types plus a union.

                    sys.std.Core.Type.Cat.Singleton
                        sys.std.Core.Type.Cat."-Inf"
                        sys.std.Core.Type.Cat.Inf

                    sys.std.Core.Type.Cat.Exception

This graph slice shows all of the catalog nonscalar types:

    sys.std.Core.Type.Universal

        sys.std.Core.Type.Tuple
            sys.std.Core.Type.DHTuple

                # The following are all regular tuple types.

                sys.std.Core.Type.Cat.Function
                    sys.std.Core.Type.Cat.NamedValFunc
                    sys.std.Core.Type.Cat.ValMapFunc
                        sys.std.Core.Type.Cat.ValMapUFunc
                        sys.std.Core.Type.Cat.ValFiltFunc
                            sys.std.Core.Type.Cat.ValConstrFunc
                    sys.std.Core.Type.Cat.TransConstrFunc
                    sys.std.Core.Type.Cat.ValRedFunc
                    sys.std.Core.Type.Cat.OrdDetFunc
                sys.std.Core.Type.Cat.IfThenExprMap
                sys.std.Core.Type.Cat.Updater
                sys.std.Core.Type.Cat.Recipe
                sys.std.Core.Type.Cat.Procedure
                    sys.std.Core.Type.Cat.SystemService
                    sys.std.Core.Type.Cat.Transaction
                sys.std.Core.Type.Cat.IfThenVarStmtMap
                sys.std.Core.Type.Cat.ScalarType
                sys.std.Core.Type.Cat.TupleType
                sys.std.Core.Type.Cat.RelationType
                sys.std.Core.Type.Cat.DomainType
                sys.std.Core.Type.Cat.SubsetType
                sys.std.Core.Type.Cat.MixinType
                sys.std.Core.Type.Cat.KeyConstr
                sys.std.Core.Type.Cat.DistribKeyConstr
                sys.std.Core.Type.Cat.SubsetConstr
                sys.std.Core.Type.Cat.DistribSubsetConstr
                sys.std.Core.Type.Cat.StimRespRule
                sys.std.Core.Type.Cat.OrderByName

                sys.std.Core.Type.Database

                    # The following are all regular database types.

                    sys.std.Core.Type.Cat.System
                    sys.std.Core.Type.Cat.MountControlCat
                    sys.std.Core.Type.Cat.Federation
                    sys.std.Core.Type.Cat.Depot
                    sys.std.Core.Type.Cat.ExprNodeSet
                    sys.std.Core.Type.Cat.StmtNodeSet
                    sys.std.Core.Type.Cat.D0

        sys.std.Core.Type.Relation
            sys.std.Core.Type.DHRelation

                # The following are all regular relation types.

                sys.std.Core.Type.Cat.SysNspSet
                sys.std.Core.Type.Cat.Sys[Function|Updater|Recipe|Procedure]Set
                sys.std.Core.Type.Cat.SysSpecTypeSet
                sys.std.Core.Type.Cat.Sys[Scalar|Tuple|Relation]TypeSet
                sys.std.Core.Type.Cat.Sys[Domain|Subset|Mixin]TypeSet
                sys.std.Core.Type.Cat.Sys[|Distrib][Key|Subset]ConstrSet
                sys.std.Core.Type.Cat.SysCatSet
                sys.std.Core.Type.Cat.MountControlSet
                sys.std.Core.Type.Cat.DepotMountSet
                sys.std.Core.Type.Cat.FedTypeMapSet
                sys.std.Core.Type.Cat.SubdepotSet
                sys.std.Core.Type.Cat.[Function|Updater|Recipe|Procedure]Set
                sys.std.Core.Type.Cat.[Scalar|Tuple|Relation]TypeSet
                sys.std.Core.Type.Cat.[Domain|Subset|Mixin]TypeSet
                sys.std.Core.Type.Cat.[|Distrib][Key|Subset]ConstrSet
                sys.std.Core.Type.Cat.StimRespRuleSet
                sys.std.Core.Type.Cat.OVLScaValExprNodeSet
                sys.std.Core.Type.Cat.ScaSelExprNodeSet
                sys.std.Core.Type.Cat.TupSelExprNodeSet
                sys.std.Core.Type.Cat.RelSelExprNodeSet
                sys.std.Core.Type.Cat.SetSelExprNodeSet
                sys.std.Core.Type.Cat.ArySelExprNodeSet
                sys.std.Core.Type.Cat.BagSelExprNodeSet
                sys.std.Core.Type.Cat.SPIvlSelExprNodeSet
                sys.std.Core.Type.Cat.MPIvlSelExprNodeSet
                sys.std.Core.Type.Cat.ListSelExprNodeSet
                sys.std.Core.Type.Cat.AccExprNodeSet
                sys.std.Core.Type.Cat.FuncInvoExprNodeSet
                sys.std.Core.Type.Cat.IfElseExprNodeSet
                sys.std.Core.Type.Cat.GivenWhenDefExprNodeSet
                sys.std.Core.Type.Cat.WhenThenExprMap
                sys.std.Core.Type.Cat.APMaterialNCSelExprNodeSet
                sys.std.Core.Type.Cat.MultiUpdStmt
                sys.std.Core.Type.Cat.RcpGlobalVarAliasMap
                sys.std.Core.Type.Cat.OVLScaValStmtNodeSet
                sys.std.Core.Type.Cat.LeaveStmtNodeSet
                sys.std.Core.Type.Cat.CompoundStmtNodeSet
                sys.std.Core.Type.Cat.NilFuncInvoStmtNodeSet
                sys.std.Core.Type.Cat.ImpInvoStmtNodeSet
                sys.std.Core.Type.Cat.IISArgVarMap
                sys.std.Core.Type.Cat.TryCatchStmtNodeSet
                sys.std.Core.Type.Cat.IfElseStmtNodeSet
                sys.std.Core.Type.Cat.GivenWhenDefStmtNodeSet
                sys.std.Core.Type.Cat.WhenThenVarStmtMap
                sys.std.Core.Type.Cat.IterateStmtNodeSet
                sys.std.Core.Type.Cat.LoopStmtNodeSet
                sys.std.Core.Type.Cat.APMaterialNCSelStmtNodeSet
                sys.std.Core.Type.Cat.PossrepSet
                sys.std.Core.Type.Cat.PossrepMapSet
                sys.std.Core.Type.Cat.VirtualAttrMapSet
                sys.std.Core.Type.Cat.ComposedMixinSet
                sys.std.Core.Type.Cat.DKMemRelAttrMap
                sys.std.Core.Type.Cat.DKRelAttrKeyAttrMap
                sys.std.Core.Type.Cat.SCChildAttrParentAttrMap
                sys.std.Core.Type.Cat.NameTypeMap
                sys.std.Core.Type.Cat.NameExprMap
                sys.std.Core.Type.Cat.NameNCMap
                sys.std.Core.Type.Cat.AttrRenameMap

This graph slice shows additional nonscalar types that can not in general
be used as components of a system catalog, or any database, but they may be
used temporarily at runtime:

    sys.std.Core.Type.Universal
        sys.std.Core.Type.Tuple

            # The following are all regular tuple types.

            sys.std.Core.Type.Cat.CurriedFuncNC
                sys.std.Core.Type.Cat.ValMapCFuncNC
                    sys.std.Core.Type.Cat.ValFiltCFuncNC
                sys.std.Core.Type.Cat.ValRedCFuncNC
                sys.std.Core.Type.Cat.OrdDetCFuncNC

This graph slice shows all of the catalog types that compose any mixin
types, shown grouped under the mixin types that they compose:

    sys.std.Core.Type.Universal

        sys.std.Core.Type.Ordered

            sys.std.Core.Type.Cat.String
            sys.std.Core.Type.Cat.Name
            sys.std.Core.Type.Cat.NameChain
            sys.std.Core.Type.Cat.Comment

            sys.std.Core.Type.Ordinal

                sys.std.Core.Type.Cat.Order
                sys.std.Core.Type.Cat."-Inf"
                sys.std.Core.Type.Cat.Inf

        sys.std.Core.Type.Stringy

            sys.std.Core.Type.Cat.String
            sys.std.Core.Type.Cat.Name
            sys.std.Core.Type.Cat.NameChain
            sys.std.Core.Type.Cat.Comment

=head1 LOW-LEVEL STRUCTURE TYPES

These types only exist in the low-level type system, and should not be used
directly by users to define their ordinary data types or variables or
parameters; rather they should use the conceptually higher-level types
declared in L<Muldis::D::Core::Types> instead as their tools.  See also
L<Muldis::D::Basics/Low Level Type System> for details of these types'
structures, how their common 5 main subtypes are defined in terms of them.

=head2 sys.std.Core.Type.Cat.List

The C<List> type is the sub-maximal type of the entire Muldis D type
system, and contains every non-C<Int> value that can possibly exist.  Every
value in the Muldis D type system is declared by just one of two types,
where C<Int> is one and C<List> is the other; therefore, C<Int> and C<List>
are each other's I<negation type>, and the union of just those 2 types is
C<Universal>.  A C<List> is a transparent dense sequence of 0..N elements
where each element is identified by ordinal position and the first element
has position zero, and where each element is either an C<Int> or a C<List>;
in the general case, this can be an arbitrarily complex hierarchical
structure of unlimited size, where the leaves of this hierarchy are each
C<Int>.  The C<List> type is neither scalar nor nonscalar et al, same as
with C<Universal>, and it contains values from all main value categories.
The default value of C<List> is C<Bool:False>.  The cardinality of this
type is infinity.

=head2 sys.std.Core.Type.Cat.Structure

C<Structure> is a proper subtype of C<List> consisting of every C<List>
value that matches one of 5 specific formats; each of those formats is
represented by exactly one of 5 mutually disjoint proper subtypes of
C<Structure>, which are: C<String>, C<Tuple>, C<Relation>, C<ScalarWP>,
C<External>; C<Structure> is a union type over all 5 of those types, and
C<Structure> has no values which are not each of one of those 5 types.  A
C<Structure> is a C<List> having at least 2 elements, where the first
element is an C<Int> in the range C<1..5> (one per each of the 5 subtypes)
that indicates how to interpret the remainder of the C<Structure> elements.
The default value of C<Structure> is C<Bool:False>.  The cardinality of
this type is infinity.

=head2 sys.std.Core.Type.Cat.Nonstructure

C<Nonstructure> is the difference type when C<Structure> is subtracted from
C<List>.  The only main reason why C<Nonstructure> exists as a named type
is to round out the 5 main broad value categories of the Muldis D type
system, where each category has its own maximal type; a nonstructure value
is any value which is neither a scalar nor a tuple nor a relation nor an
external.  The default value of C<Nonstructure> is the sole C<List> value
with zero elements.  The cardinality of this type is infinity.

=head1 SIMPLE GENERIC SCALAR TYPES

=head2 sys.std.Core.Type.Cat.ScalarWP

C<ScalarWP> (scalar with possreps) is a proper subtype of C<Scalar> where
every one of its values has at least one possrep.  C<ScalarWP> is just the
difference type where both C<Int> and C<String> are subtracted from
C<Scalar>.  Its default value is C<Bool:False>.  The cardinality of this
type is infinity.  Considering the low-level type system, C<ScalarWP> is
just a proper subtype of C<Structure> consisting of every
C<Structure> value whose first element is the C<Int> value C<4>.

=head2 sys.std.Core.Type.Cat.DHScalarWP

C<DHScalarWP> is the intersection type of C<ScalarWP> and C<DHScalar>.  Its
default value is C<Bool:False>, same as both of its parent types.  The
cardinality of this type is infinity.  All Muldis D scalar values that are
allowed to be stored in a global/persisting relational database, besides
C<Int> and C<String> values, are C<DHScalarWP> values.

=head2 sys.std.Core.Type.Cat.OVLScalar

The C<OVLScalar> type is explicitly
defined as a union type over all system-defined C<DHScalar> types, and just
those types, for whose values all of the Muldis D standard dialects provide
"opaque value literal" syntax for:  C<Bool>, C<Int>, C<Rat>, C<Blob>,
C<Text>, C<Name>, C<NameChain>, C<Comment>, C<Order>,
C<RoundMeth>, C<RatRoundRule>, C<Singleton>.  The C<OVLScalar> type is
mainly intended to be used as the declared type of some attributes of some
other system-defined catalog types, as a compact or hard-coded way to
represent scalar values that are I<not> being specified explicitly in terms
of possrep attributes.  The C<OVLScalar> type is I<not> intended to be used
as the declared type of any user type attributes, generally speaking; if
they would even consider it, they should be using C<DHScalar> instead.  Its
default value is C<Bool:False>.  The cardinality of this type is infinity.

=head2 sys.std.Core.Type.Cat.String

A C<String> is a string of integers, or more specifically it is a dense
sequence of 0..N elements (I<not> defined over C<Relation>) where each
element is an C<Int>.  The C<String> type explicitly composes the
C<Stringy> mixin type.  A C<String> subtype is normally composed into any
system-defined type that is conceptually a string of integers or bits or
characters, such as C<Blob> or C<Text>.  The C<String> type's default and
canonical minimum value is the empty sequence; its canonical maximum value
is an infinite-length sequence and practically impossible.  C<String> is
one of just two scalar root types (the other is C<Int>) that do I<not> have
any possreps.  The cardinality of this type is infinity; to define a
most-generalized finite C<String> subtype, you must specify a maximum
length in elements that the subtype's values can have, and you must specify
the 2 integer end-points of the inclusive range that all its values' C<Int>
element values are in.  The C<String> type explicitly composes the
C<Ordered> mixin type.  The C<String> type has a default ordering
algorithm; for 2 distinct C<String> values, their order is determined as
follows:  First eliminate any identical leading element sequences from both
strings as those alone would make the strings compare as same (if the
remainder of both strings was the empty string, then the strings are
identical).  Then, iff the remainder of just one string is the empty
string, then that string is ordered before the non-empty one; otherwise,
compare the first element of each of the string remainders according to the
default ordering algorithm of C<Int> to get the order of their respective
strings.  Considering the low-level type system, C<String> is just a proper
subtype of C<Structure> consisting of every C<Structure> value whose first
element is the C<Int> value C<1>.

=head2 sys.std.Core.Type.Cat.BString

C<BString> (bit string) is a proper subtype of C<String> where all member
value elements are between zero and 1 inclusive.  One can be used to
represent a string of bits.  Considering the low-level type system, for
every C<BString> value, its second C<Structure> element is the C<Int> value
C<-1> (bit string).

=head2 sys.std.Core.Type.Cat.OString

C<OString> (octet string) is a proper subtype of C<String> where all member
value elements are between zero and 255 inclusive.  One can be used to
represent a string of octets.  Considering the low-level type system, for
every C<OString> value, its second C<Structure> element is the C<Int> value
C<-2> (octet string).

=head2 sys.std.Core.Type.Cat.UCPString

C<UCPString> (Unicode abstract codepoint string) is a proper subtype of
C<String> where all member value elements are between zero and F;D7FF
inclusive or F;E000 and F;10FFFF inclusive.  As of the Unicode standard
version 5.2.0, all character abstract codepoints exist within that range,
and so each element could be used to represent any Unicode character and
the whole string can be used to represent a string of Unicode characters.
Considering the low-level type system, for every C<UCPString> value, its
second C<Structure> element is the C<Int> value C<-4> (text with Unicode
5.2.0 canonical character repertoire).  I<Support in Muldis D for the
Unicode compatibility repertoire, other character repertoires is pending.>

There are no Unicode abstract codepoints between F;D800 and F;DFFF
inclusive; those numbers would only represent special surrogates that do
not define extra abstract characters and only have any meaning in
conjunction with the UTF-16 character encoding form; and so the
C<UCPString> type specifically excludes them from use in its member values;
you must just use the normal character abstract codepoints instead.

=head2 sys.std.Core.Type.Cat.Name

A C<Name> (scalar) is a canonical short
name for any kind of DBMS entity (or named component) when declaring it;
this short name is sufficient to identify the entity within its immediate
namespace.  Similarly, a DBMS entity can often be invoked or referred to
using just its C<Name>, depending on the context; other times, a
C<NameChain> must be used instead to also qualify the reference with a
namespace.  The C<Name> type explicitly composes the C<Stringy> mixin
type.  A C<Name> has 1 system-defined possrep whose name is the empty
string, which has 1 C<Text>-typed attribute whose name is the empty
string.  The C<Name> type explicitly composes the C<Ordered> mixin type.
A C<Name> is a simple wrapper for a C<Text> and all of its other
details such as default and minimum and maximum values and cardinality and
default ordering algorithm all correspond directly.  But C<Name> is
explicitly disjoint from C<Text> due to having a different intended
interpretation; it is specifically intended for use in naming DBMS entities
rather than being for general-purpose user data.

=head2 sys.std.Core.Type.Cat.NameChain

A C<NameChain> (scalar) is a canonical long
name for invoking or referring to a DBMS entity, when its name needs to be
qualified with a namespace.  A C<NameChain> is used in declaring system
catalogs where DBMS entities live under a potentially N-depth namespace,
such as depot entities grouped in a
subdepot hierarchy.  The C<NameChain> type explicitly composes the
C<Stringy> mixin type.  A C<NameChain> is conceptually a sequence of
0..N C<Name>, the 0..N elements being ordered from parent-most to
child-most component name.  A C<NameChain> has 1 system-defined possrep
named C<array> which directly matches the conception of the type; it
consists of 1 attribute whose name is the empty string; the attribute is an
C<Array> whose C<value> attribute has a declared type of C<Name>.  The
default and minimum value of
C<NameChain> is a zero element sequence; its maximum value is an infinite
sequence where each element is the maximum value of C<Name> (an
infinite-length string) and practically impossible.  The cardinality of
this type is infinity; to define a most-generalized finite C<NameChain>
subtype, you must specify a maximum number of sequence elements of its
values, and each element must be of a finite C<Name> subtype.  The
C<NameChain> type explicitly composes the C<Ordered> mixin type.  The
C<NameChain> type has a default ordering algorithm; for 2 distinct
C<NameChain> values, their order is determined as follows:  First eliminate
any identical parent-most elements from both chains as those alone would
make the chains compare as same (if the remainder of both chains was the
empty chain, then the chains are identical).  Then, iff the remainder of
just one chain is the empty chain, then that chain is ordered before the
non-empty one; otherwise, compare the first element of each of the chain
remainders according to the default ordering algorithm of C<Name> to get
the order of their respective chains.

=head2 sys.std.Core.Type.Cat.PNSQNameChain

C<PNSQNameChain> (primary namespace
qualified name chain) is a proper subtype of C<NameChain> where every
member value's chain starts with one of the following element sequences:
C<sys.[cat|std|imp]>, C<mnt.cat>, C<fed.[cat|lib|data]>,
C<nlx[.par]**0..*.[cat|lib|data]>, C<rtn>, C<type>.  I<The
definition of the type is actually more restrictive than this, as per the
balance of the invariant rules of the primary namespaces in question, but
those aren't detailed here for brevity.>  One can be used to reference a
material (routine or type or etc) for invocation, either system-defined or
user-defined, or one can be used to reference a variable (or
pseudo-variable or parameter or named expression or statement), either a
system-catalog or normal data variable.  Its default value is a reference
to the C<sys.std.Core.Type.Universal> type.

=head2 sys.std.Core.Type.Cat.MaterialNC

C<MaterialNC> is a proper subtype of
C<PNSQNameChain> where every member value's chain starts with one of the
following element sequences: C<sys.[std|imp]>, C<fed.lib>,
C<nlx[.par]**0..*.lib>, C<rtn>, C<type>.  One can be used to reference a
material (routine or type or etc) for invocation, either system-defined or
user-defined.  Its default value is a reference to the
C<sys.std.Core.Type.Universal> type.

=head2 sys.std.Core.Type.Cat.AbsPathMaterialNC

C<AbsPathMaterialNC> is a proper subtype
of C<MaterialNC> where every member value's chain starts with either C<sys>
or C<fed> (or a C<type>-prefix followed by those) but not C<nlx> or C<rtn>.
One is used when conceptually a routine or type is being passed as an
argument to a routine, such as because it is a higher-order function or
closure, and it is in fact the name of the invocant being passed; only an
absolute path can be used in this situation for the general case because
the target is being invoked from a different context than where the
reference to the target is being selected; a relative path doesn't work
because C<nlx> or C<rtn> means something different on each side of the
NC-argument-taking-routine.  Conceptually speaking, an C<AbsPathMaterialNC>
that points to a routine I<is> a closure, or a higher-order function if it
points to a function.

=head2 sys.std.Core.Type.Cat.APFunctionNC

C<APFunctionNC> is a proper subtype of
C<AbsPathMaterialNC> that excludes the C<type>-prefix values and a subset
of the C<sys>-prefix values.  Its default value is a reference to the
C<sys.std.Core.Universal.is_identical> function.

=head2 sys.std.Core.Type.Cat.APImperativeNC

C<APImperativeNC> is a proper subtype of
C<AbsPathMaterialNC> that excludes the C<type>-prefix values and a subset
of the C<sys>-prefix values.  Its default
value is a reference to the C<sys.std.Core.Universal.assign> updater.

=head2 sys.std.Core.Type.Cat.APTypeNC

C<APTypeNC> is a proper subtype of C<AbsPathMaterialNC> that excludes a
subset of the C<sys>-prefix values.  Its default value is a reference to
the C<sys.std.Core.Type.Universal> data type.

=head2 sys.std.Core.Type.Cat.RelPathMaterialNC

C<RelPathMaterialNC> is a proper subtype
of C<MaterialNC> where every member value's chain starts with either C<sys>
or C<nlx> or C<rtn> (or a C<type>-prefix followed by those) but not C<fed>.
One is used in a context where a user-defined routine or type may only be
invoked directly when both the invoker and invoked are in the same depot.

=head2 sys.std.Core.Type.Cat.RPFunctionNC

C<RPFunctionNC> is a proper subtype of C<RelPathMaterialNC> that excludes
the C<type>-prefix values and a subset of the C<sys>-prefix values.  Its
default value is a reference to the C<sys.std.Core.Universal.is_identical>
function.

=head2 sys.std.Core.Type.Cat.RPImperativeNC

C<RPImperativeNC> is a proper subtype of C<RelPathMaterialNC> that excludes
the C<type>-prefix values and a subset of the C<sys>-prefix values.  Its
default value is a reference to the C<sys.std.Core.Universal.assign>
updater.

=head2 sys.std.Core.Type.Cat.RPTypeNC

C<RPTypeNC> is a proper subtype of C<RelPathMaterialNC> that excludes the
C<rtn> value and a subset of the C<sys>-prefix values.  Its default value
is a reference to the C<sys.std.Core.Type.Universal> data type.

=head2 sys.std.Core.Type.Cat.DataNC

C<DataNC> is a proper subtype of
C<PNSQNameChain> where every member value's chain starts with one of the
following element sequences: C<sys.cat>, C<mnt.cat>, C<fed.[cat|data]>,
C<nlx[.par]**0..*.[cat|data]>.  One can be used to reference a
variable (or pseudo-variable or parameter or named expression or
statement), either a system-catalog or normal data variable.  Its default
value is a reference to the C<sys.cat> catalog relcon.
I<Conjecture:  Subtypes like C<[Abs|Rel]PathDataNC> might also be defined
later if we have some situation where such a restriction might be useful.>

=head2 sys.std.Core.Type.Cat.Comment

A C<Comment> (scalar) is the text of a
Muldis D code comment, which programmers can populate as an attribute of
several catalog data types, such as whole routines or statements or
expression nodes.  The C<Comment> type explicitly composes the C<Stringy>
mixin type.  The C<Comment> type explicitly composes the
C<Ordered> mixin type.  Every detail of C<Comment>'s representation (its 1
possrep, default value and ordering algorithm, etc) is the same as C<Name>
but it is explicitly disjoint due to having a different intended
interpretation; it is intended just for commenting Muldis D code.  One main
intended use of this type is to help preserve comments in code translated
to or from other languages; though only a subset of those (FoxPro?) keep
comments in the AST rather than discarding them.

=head2 sys.std.Core.Type.Cat.Order

The C<Order> (order determination) type
is explicitly defined as a union type over just these 3 singleton types
having C<sys.std.Core.Type.Cat.Order.*>-format names:
C<Increase>, C<Same>, C<Decrease>.  When some context
(such as within a list sort or range check operation) needs to know the
relative order of 2 values according to some criteria, it can invoke a
function that applies that criteria to those 2 values, which are its
main/only arguments, and that function results in an C<Order> value for the
context to make use of.  The
default value of C<Order> is C<Same>; its minimum and maximum values are,
respectively, C<Increase> and C<Decrease>.  The cardinality of this type is
3.  The C<Order> type explicitly composes the C<Ordinal> mixin type, and by
extension also implicitly composes the C<Ordered> mixin type.
The C<Order> type has a default ordering algorithm that corresponds
directly to the sequence in which its values are documented here;
C<Increase> is ordered before C<Same>, and C<Same> before C<Decrease>.

=head2 sys.std.Core.Type.Cat.Order.*

There are exactly 3 types having C<sys.std.Core.Type.Cat.Order.*>-format;
for the rest of this
description, the type name C<Order.Value> will be used as a proxy for each
and every one of them.  A C<Order.Value> has 1 system-defined possrep whose
name is the empty string and which has zero attributes.  The cardinality of
this type is 1, and its only value is its default and minimum and maximum
value.

=head2 sys.std.Core.Type.Cat.RoundMeth

The C<RoundMeth> (rounding method)
type is explicitly defined as a union type over just these 9 singleton
types having C<sys.std.Core.Type.Cat.RoundMeth.*>-format names:
C<Down>, C<Up>, C<ToZero>, C<ToInf>, C<HalfDown>, C<HalfUp>, C<HalfToZero>,
C<HalfToInf>, C<HalfEven>.  When a value
of some ordered type needs to be mapped into a proper subtype that doesn't
contain that value, such as when mapping an arbitrary number to one with
less precision, some rounding method is applied to determine which value of
the subtype is to be mapped to while most accurately reflecting the
original value.  The C<RoundMeth> type enumerates the rounding methods
that Muldis D operators can typically apply.  With C<Down> (aka I<floor>),
C<Up> (aka I<ceiling>), C<ToZero> (aka I<truncate>), and C<ToInf>, the
original value will always be mapped to the single adjacent value that is
lower than it, or higher than it, or towards "zero" from it, or towards the
nearer infinity from it, respectively.  With C<HalfDown>,
C<HalfUp>, C<HalfToZero>, C<HalfToInf>,
and C<HalfEven> (aka I<unbiased rounding>, I<convergent
rounding>, I<statistician's rounding>, or I<bankers' rounding>), the
original value will be mapped to the single target value that it is closest
to, if there is one; otherwise, if it is exactly half-way between 2
adjacent target values, then C<HalfDown> will round towards negative
infinity, C<HalfUp> will round towards positive infinity,
C<HalfToZero> will round towards "zero", C<HalfToInf> will round towards
the nearer infinity, and C<HalfEven> will round towards the nearest "even"
target.  The default value of C<RoundMeth> is C<HalfEven>, since in general
that should be the most likely to minimize the rounding error from a
sequence of operations that each round, which is especially useful in
contexts where a rounding method is implicit.  The
C<RoundMeth> type does I<not> have a default ordering algorithm.

=head2 sys.std.Core.Type.Cat.RoundMeth.*

There are exactly 9 types having
C<sys.std.Core.Type.Cat.RoundMeth.*>-format names;
for the rest of this description, the type name
C<RoundMeth.Value> will be used as a proxy for each and every one of
them.  A C<RoundMeth.Value> has 1 system-defined possrep whose name is
the empty string and which has zero attributes.  The cardinality of this
type is 1, and its only value is its default and minimum and maximum value.

=head2 sys.std.Core.Type.Cat.RatRoundRule

A C<RatRoundRule> (scalar) specifies a
controlled (and typically degrading) coercion of a real number into a
rational number having a specific radix and precision.  It is mainly used
to deterministically massage an operation, whose conceptual result is
generally an irrational number, so that its actual result is a best
approximating rational number.  It is also used to define a generic
rounding operation on a rational number that derives a typically less
precise rational.  A C<RatRoundRule> has 1 system-defined possrep whose
name is the empty string, which has these 3 attributes: C<radix> (a
C<PInt2_N>), C<min_exp> (an C<Int>), and C<round_meth> (a C<RoundMeth>).
The rational resulting from the operation is as close as possible to the
conceptual result but that it is an exact multiple of the rational value
resulting from C<radix> taken to the power of C<min_exp>; if rounding is
needed, then C<round_meth> dictates the rounding method.  The default value
of C<RatRoundRule> specifies a coersion to a whole number using the
C<HalfEven> rounding method (its radix is 2 and its min exp is 0).  The
C<RatRoundRule> type does I<not> have a default ordering algorithm.

=head2 sys.std.Core.Type.Cat.Singleton

The C<Singleton> type is explicitly defined as a union type over just the
system-defined core singleton types which aren't otherwise included in
another union type specific to a group of singleton types.  C<Singleton>
only exists as a convenience for concrete Muldis D grammars that want to
have a group type name for every system-defined opaque value.  C<Singleton>
currently unions just these 2 types: C<-Inf>, C<Inf>.

=head2 sys.std.Core.Type.Cat."-Inf"

C<-Inf> is a singleton scalar type whose only value represents negative
infinity.  It is intended for use as a special value in contexts that are
sensitive to the ordering of a type's values, wherein it can be the
canonical minimum-most value, and so would be ordered before every other
possible value of C<Universal> that it might be compared with.  A C<-Inf>
has 1 system-defined possrep whose name is the empty string and which has
zero attributes.  The cardinality of this type is 1, and its only value is
its default and minimum and maximum value.  The only value of C<-Inf> is
also known as C<-∞>.  C<-Inf> explicitly composes C<Ordinal>.

=head2 sys.std.Core.Type.Cat.Inf

C<Inf> is a singleton scalar type whose only value represents positive
infinity.  It is the same as C<-Inf> in every way except it is the
canonical maximum-most value rather than minimum-most.  The only value of
C<Inf> is also known as C<∞>.  C<Inf> explicitly composes C<Ordinal>.

=head1 TYPES FOR DEFINING SYSTEM-DEFINED ENTITIES

=head2 sys.std.Core.Type.Cat.System

A C<System> is a C<Database>.  It specifies the public interfaces of
system-defined entities, specifically all the system-defined types,
routines, and catalogs.  Both standard system-defined entities and
implementation-specific system-defined entities are specified here,
specifically all the relcons and relvars with the names
C<[sys|mnt|fed|nlx].cat>.  The system catalog constant named
C<sys.cat> is of the C<System> type.

A C<System> has these 18 attributes:

=over

=item C<scm_comment> - C<just_of.Comment>

This is an optional programmer comment about the collection of
system-defined entities as a whole.

=item C<namespaces> - C<SysNspSet>

These are all the system-defined namespaces where not-lexical DBMS entities
may live, or that otherwise always exist due to being system-defined.
Specifically, it declares these 18 standard language namespaces:
C<[sys|mnt|fed|nlx|rtn]> (which have the nameless global
root namespace as their parent, spelled as the empty C<NameChain>
value, that isn't also declared here), C<sys.[cat|std|imp]>,
C<mnt.cat>, C<[fed|nlx].[cat|lib|data]>, C<sys.std.Core>,
C<sys.std.Core.Type>, C<sys.std.Core.Type.Cat>; it also declares other
C<Core> namespaces, and where applicable, standard extensions or
implementation-specific extensions.

=item C<functions|updaters|recipes|procedures> -
C<Sys[Function|Updater|Recipe|Procedure]Set>

These are the interfaces, or definitions in some cases, of all the
system-defined functions|updaters|recipes|procedures.

=item C<special_types> - C<SysSpecTypeSet>

These are the few central system-defined data types that have special
hard-coded meanings and are not defined like any other types; these are
declarations of all of the native Muldis D types that can't be defined like
user-defined types.  Specifically, it declares these 4 standard types: in
the C<sys.std.Core.Type> namespace: C<Universal>, C<Empty>, C<Int>; in the
C<sys.std.Core.Type.Cat> namespace: C<List>.  These constitute all 2 Muldis
D declaration types, all 2 Muldis D type system maximal and minimal
(enumeration) types.  Note that, while conceptually both C<Universal> and
C<Empty> I<can> be defined like user-defined types, as the union or
intersection of C<Int> and C<List>, respectively, in practice that wouldn't
work for C<Empty> at least because all user-defined types are required to
have a default value and it can't, and C<Universal> is also kept here at
least to balance C<Empty>; actually, the maximal and minimal types are used
in many places as default semantics in non-special type definitions.

=item C<[scalar|tuple|relation|domain|subset|mixin]_types> -
C<Sys[Scalar|Tuple|Relation|Domain|Subset|Mixin]TypeSet>

These are all the system-defined scalar types, except for C<Int> because it
can't be defined like user-defined types, and complete tuple and relation
types, and domain types, and subset types, and mixin types.

=item C<[|distrib_][key|subset]_constrs> -
C<[|Distrib][Key|Subset]ConstrSet>

These are all the system-defined |distributed key|subset constraints.

=item C<catalogs> - C<SysCatSet>

These are the interfaces of all the catalog relcons and relvars.
Specifically, it declares these 4 standard catalogs:
C<[sys|mnt|fed|nlx].cat>; the first is a relcon, the others not.

=back

The default value of C<System> defines a system with zero builtins.

=head2 sys.std.Core.Type.Cat.SysNspSet

A C<SysNspSet> is a C<DHRelation> that specifies the set of system
namespaces that exist for organizing DBMS public entities, mostly the
system-defined ones; these system namespaces are organized into a tree
whose root has no name.  A C<SysNspSet> only specifies that a system
namespace exists, not which public entities it contains; see the
C<System> which contains it for that.

A C<SysNspSet> has these 4 attributes:

=over

=item C<parent> - C<NameChain>

This is the fully-qualified name, in the nameless global root namespace, of
the system namespace's parent system namespace.

=item C<name> - C<Name>

This is the declared name of the system namespace within the namespace
defined by C<parent>; other Muldis D code would reference it with the
combination of C<parent> and C<name>.

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about this specific system
namespace.

=item C<scm_vis_ord> - C<NNInt>

This is the visible order of this namespace's declaration relative to all
of the named entities directly within the namespace defined by C<parent>.

=back

A C<SysNspSet> has a binary primary key on the C<parent> plus
C<name> attributes.  Its default value is empty.

=head2 sys.std.Core.Type.Cat.Sys[Function|Updater|Recipe|Procedure]Set

A C<Sys[Function|Updater|Recipe|Procedure]Set> is a C<DHRelation> that
specifies a set of system-defined functions|updaters|recipes|procedures.

A C<Sys[Function|Updater|Recipe|Procedure]Set> has these 5 attributes:

=over

=item C<parent> - C<NameChain>

This is the fully-qualified name, in the nameless global root namespace, of
the function|updater|recipe|procedure's parent system namespace.

=item C<name> - C<Name>

This is the declared name of the function|updater|recipe|procedure within
the namespace defined by C<parent>; other Muldis D code would reference it
with the combination of C<parent> and C<name>.

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about the
function|updater|recipe|procedure as a whole.

=item C<scm_vis_ord> - C<NNInt>

This is the visible order of this routine's declaration relative to all of
the named entities directly within the namespace defined by C<parent>.

=item C<material> - C<Function|Updater|Recipe|Procedure>

This defines the entire function|updater|recipe|procedure sans its name.
Note that it is not mandatory for a system-defined routine to have a
specified I<body> (just a specified I<heading> is mandatory), and often it
won't; but often it will, especially if it is a function used in the
definition of a system-defined data type.

=back

A C<Sys[Function|Updater|Recipe|Procedure]Set> has a binary primary key on
the C<parent> plus C<name> attributes.  Its default value is empty.

=head2 sys.std.Core.Type.Cat.SysSpecTypeSet

A C<SysSpecTypeSet> is a C<DHRelation> that specifies a set of
system-defined types which are particularly special and unlike other types;
it is used for declaring all system types that can't be defined like user
types.

A C<SysSpecTypeSet> has these 4 attributes:

=over

=item C<parent> - C<NameChain>

This is the fully-qualified name, in the nameless global root namespace, of
the type's parent system namespace.

=item C<name> - C<Name>

This is the declared name of the type within the namespace defined by
C<parent>; other Muldis D code would reference it with the combination of
C<parent> and C<name>.

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about the type as a whole.

=item C<scm_vis_ord> - C<NNInt>

This is the visible order of this type's declaration relative to all of
the named entities directly within the namespace defined by C<parent>.

=back

A C<SysSpecTypeSet> has a binary primary key on the C<parent> plus
C<name> attributes.  Its default value is empty.

=head2 sys.std.Core.Type.Cat.Sys[Scalar|Tuple|Relation|Domain|Subset|Mixin]TypeSet

A C<Sys[Scalar|Tuple|Relation|Domain|Subset|Mixin]TypeSet> is a
C<DHRelation> that specifies a set of
system-defined scalar|tuple|relation|domain|subset|mixin types.

A C<Sys[Scalar|Tuple|Relation|Domain|Subset|Mixin]TypeSet> has these 5
attributes:

=over

=item C<parent> - C<NameChain>

This is the fully-qualified name, in the nameless global root namespace, of
the scalar|tuple|relation|domain|subset|mixin type's parent system
namespace.

=item C<name> - C<Name>

This is the declared name of the scalar|tuple|relation|domain|subset|mixin
type within the namespace defined by C<parent>; other Muldis D code would
reference it with the combination of C<parent> and C<name>.

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about the
scalar|tuple|relation|domain|subset|mixin type as a whole.

=item C<scm_vis_ord> - C<NNInt>

This is the visible order of this type's declaration relative to all of
the named entities directly within the namespace defined by C<parent>.

=item C<material> - C<[Scalar|Tuple|Relation|Domain|Subset|Mixin]Type>

This defines the entire scalar|tuple|relation|domain|subset|mixin type sans
its name.

=back

A C<Sys[Scalar|Tuple|Relation|Domain|Subset|Mixin]TypeSet> has a binary
primary key on the C<parent> plus C<name> attributes.  Its default value is
empty.

=head2 sys.std.Core.Type.Cat.Sys[|Distrib][Key|Subset]ConstrSet

A C<Sys[|Distrib][Key|Subset]ConstrSet> is a C<DHRelation> that specifies a
set of system-defined |distributed key|subset constraints.

A C<Sys[|Distrib][Key|Subset]ConstrSet> has these 5 attributes:

=over

=item C<parent> - C<NameChain>

This is the fully-qualified name, in the nameless global root namespace, of
the |distributed key|subset constraint's parent system namespace.

=item C<name> - C<Name>

This is the declared name of the |distributed key|subset constraint within
the namespace defined by C<parent>; other Muldis D code would reference it
with the combination of C<parent> and C<name>.

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about the |distributed key|subset
constraint as a whole.

=item C<scm_vis_ord> - C<NNInt>

This is the visible order of this constraint's declaration relative to all
of the named entities directly within the namespace defined by C<parent>.

=item C<material> - C<[|Distrib][Key|Subset]Constr>

This defines the entire |distributed key|subset constraint sans its name.

=back

A C<Sys[|Distrib][Key|Subset]ConstrSet> has a binary primary key on the
C<parent> plus C<name> attributes.  Its default value is empty.

=head2 sys.std.Core.Type.Cat.SysCatSet

A C<SysCatSet> is a C<DHRelation> that specifies a set of system-defined
catalog dbvars; each tuple specifies one catalog dbvar.

A C<SysCatSet> has these 5 attributes:

=over

=item C<name> - C<DataNC>

This is the fully-qualified name of the catalog dbvar.

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about the catalog dbvar as a whole.

=item C<scm_vis_ord> - C<NNInt>

This is the visible order of this catalog's declaration relative to all of
the other catalogs.

=item C<is_readonly> - C<Bool>

This is C<Bool:True> if a catalog relcon is being described; it is
C<Bool:False> if a catalog relvar is being described.

=item C<catalog> - C<MaterialNC>

This is the declared data type of the catalog dbvar.

=back

A C<SysCatSet> has a unary primary key on the C<name> attribute.  Its
default value is empty.

=head1 TYPES FOR DEFINING MOUNT CONTROLS

=head2 sys.std.Core.Type.Cat.MountControlCat

A C<MountControlCat> is a C<Database>.  It specifies the control
interface for mounting and unmounting (and creating and deleting) depots
within the current in-DBMS process.  The scope of these controls includes
specifying what name the depot is mounted with, whether the mount is
readonly vs updateable, or is temporary vs persistant, and implementation
specific details like storage file names or network login credentials.
Updates to this catalog have side-effects in what other user-updateable
catalogs exist, making them appear or disappear.  This catalog may only be
updated when the current process has no active transaction.  The system
catalog variable named C<mnt.cat> is of the C<MountControlCat> type.

A C<MountControlCat> has these 2 attributes:

=over

=item C<scm_comment> - C<just_of.Comment>

This is an optional programmer comment about the depot mount control
catalog as a whole.

=item C<mounts> - C<MountControlSet>

These are the controls for the current depot mounts.

=back

The default value of C<MountControlCat> has zero depot mount controls.

=head2 sys.std.Core.Type.Cat.MountControlSet

A C<MountControlSet> is a C<DHRelation> that specifies a set of controls
per depot mounts, such that each tuple is a single control for a depot
mount, and each depot mount has 1 mount control.  Inserting a tuple will
result in either an existing depot being mounted or a new depot being
created (if possible) and mounted; updating a tuple will change some
details of that depot mount's status, such as making it readonly or
updateable; deleting a tuple will result in a mounted depot being either
unmounted or unmounted plus deleted (if possible).

A C<MountControlSet> has these 8 attributes:

=over

=item C<name> - C<Name>

This is the declared name of the depot mount; other Muldis D code would
reference it with this name.

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about this specific mount of the
depot.

=item C<is_temporary> - C<Bool>

This is C<Bool:True> if the depot mount is for a transient depot that would
automatically be created when mounted I<and> automatically be deleted when
unmounted, because it is only intended for use as the application's current
working memory, and its maximum lifetime is the lifetime of the in-DBMS
process.  This is C<Bool:False> (the default) if the depot mount is for a
depot that either should already exist before being mounted, I<or> that
should continue to exist after being unmounted, because it is intended for
persistent data.  Note that the C<is_temporary> status is orthogonal to
whether the depot's storage is in volatile memory (eg, RAM) or in stable
memory (eg, on disk); a I<not-temporary> depot is simply one that is meant
to be reusable by multiple depot mounts or processes.  The C<is_temporary>
status may not be updated on an existing depot mount control.  I<These
details are subject to revision.>

=item C<create_on_mount> - C<Bool>

This is C<Bool:True> if the depot mount must represent a depot that was
newly created at the time the depot mount was created, where the depot
creation is a direct side-effect of the mount operation.  This is
C<Bool:False> (the default) if the depot being mounted must already exist
without the mounting process having any hand in creating it.  Note that
there is no option provided to conditionally create a depot depending on
whether it already exists, as a perceived safety feature (this detail is
subject to change); to get that behaviour, first try creating the depot
mount control with this attribute C<Bool:False>, and if that fails due to
nonexistence, then try again with it set to C<Bool:True>.  This attribute
is ignored / not applicable when C<is_temporary> is true.

=item C<delete_on_unmount> - C<Bool>

This is C<Bool:True> if the depot should be deleted at the same time it is
unmounted, that is, when this depot mount control tuple is deleted.  This
is C<Bool:False> (the default) if the depot should not be deleted as part
of the unmount process.  This attribute is ignored / not applicable when
C<is_temporary> is true.

=item C<we_may_update> - C<Bool>

This is C<Bool:True> if the depot mount will permit the current in-DBMS
process to make any kind of update to the depot, such as data manipulation,
data definition, or creating/deleting it.  This is C<Bool:False> (the
default) if the depot mount is only providing readonly access to the depot.
When a depot mount is readonly, any attempt to update the depot through it
will throw a runtime exception.  The C<we_may_update> attribute may be set
to C<Bool:False> at any time (when there is no active transaction), but it
may only be set to C<Bool:True> at the time the depot is mounted; this is
for safety, such that if a depot mount won't let you update the depot now,
there's no way it will let you update it later, save by unmounting and
remounting the depot (the result of which is a different depot mount).
Note that the C<we_may_update> status is orthogonal to the depot locking
mechanism; it won't block any other process from reading or updating that
depot, so unless you have locks on the depot using some other means, it may
still be updated by others while mounted readonly for you, so consistent
reads between distinct statements outside of transactions are not
guaranteed.  I<These details are subject to revision, such as in regards to
what autonomous child processes of the current process may do.>

=item C<allow_auto_run> - C<Bool>

This is C<Bool:True> if the depot mount will permit any stimulus-response
rules defined in the depot to automatically execute when triggering events
occur; those events could be nearly anything, including the very act of
mounting (or unmounting) that depot.  This is C<Bool:False> (the default)
if the depot mount will prohibit all stimulus-response rules defined in the
depot from automatically executing.  The primary purpose of the
C<allow_auto_run> attribute is to provide a measure of security against
viruses and other malware that are using Muldis D databases as a vector,
especially where the malicious code is setup to run automatically as soon
as its host depot is mounted, which is insidious because in general users
have to mount a depot in order to even examine it to see if its contents
are safe, at which point it is too late.  When you have a depot with a
dubious history, mounting it initially with a false C<allow_auto_run> will
allow you to examine the depot for malware without giving the latter any
opportunity to run; moreover, you will be able to clean out a virus
infection from a depot that you otherwise wish to preserve (it is just
data, after all); and then you can remount the depot with a true
C<allow_auto_run> once you know it is clean, in order for benign
auto-running code to work.  If a depot is "the main program" in a pure
Muldis D application, then C<allow_auto_run> must be C<Bool:True> in order
for it to work properly since auto-running is how the initial Muldis D
routine of a call chain is invoked, and otherwise the program will
immediately exit on launch without doing anything.  When C<allow_auto_run>
is C<Bool:False> (and C<we_may_update> is C<Bool:True>), then the depot's
catalog dbvar is updateable, so that you can purge any viruses, but the
depot's data dbvar is read-only, because in the general case there may be
some database constraints or benign side-effects of data manipulation that
would be prevented from doing their jobs because they are defined as
stimulus-response rules, and allowing data manipulation then could lead to
violations of otherwise-enforced business rules.  Note that a false
C<allow_auto_run> will not prohibit you from manually invoking code in the
depot, so be careful not to invoke something unsafe.  Note that having a
false C<we_may_update> status alone isn't adequate protection against
malware because even in that situation any stimulus-response rules whose
triggers aren't data manipulation events will still automatically run, and
the malware can still do all sorts of harm, since stimulus-response rules
in general can do anything a C<procedure> can, including various I/O or
manipulating other depots.

=item C<details> - C<OVLScaValExprNodeSet>

These are the 0..N other miscellaneous details that define this depot mount
control.  Each tuple in C<details> specifies an implementation-specific
attribute name and (scalar) value.  Example such implementation-specific
details include the name of a local file that the depot is stored as, or
the name of a DBMS server on the network plus authentication credentials to
connect to it with.  See each Muldis D implementation for details.  Note
that C<details> generally corresponds to the Perl DBI's concept of a data
source name or connection string.  But C<details> can also have other
details like customizations on how to map a foreign DBMS' concepts to
native Muldis D equivalents, or maybe information on where to find extra
metadata that has such info, or info to instruct a Muldis D interface to
fill in functionality missing in the actual depot of a less capable DBMS,
like constraints or stored invokable routines.

=back

A C<MountControlSet> has a unary primary key on the C<name> attribute.
Its default value is empty.  It also has a transition constraint that
prevents changing some attributes of a depot mount control once set.  Note
that the 3 attributes [C<is_temporary>, C<create_on_mount>,
C<delete_on_unmount>] may be merged into a single enumerated-typed
attribute or otherwise be reorganized.

=head1 TYPES FOR DEFINING FEDERATIONS

=head2 sys.std.Core.Type.Cat.Federation

A C<Federation> is a C<Database>.  It specifies a federation of depot
mounts, that is, all the depot mounts that an in-DBMS process can see or
update, and that defines the scope of an active transaction.  There is
exactly one of these per process and it doesn't have a name.  The system
catalog variable named C<fed.cat> is of the C<Federation> type.

A C<Federation> has these 3 attributes:

=over

=item C<scm_comment> - C<just_of.Comment>

This is an optional programmer comment about the federation as a whole.

=item C<mounts> - C<DepotMountSet>

These are the depot mounts that comprise the federation.

=item C<type_maps> - C<FedTypeMapSet>

When this federation has more than one depot mount, and the depots have
copies of the same data types, then C<type_maps> is used to specify which
types in each depot correspond to types in others, so that during the time
period of common mounting, those data types can be treated as aliases and
so be used interchangeably.  Mainly this is used when either a procedure in
one depot wants to access or update a dbvar of another depot, or when a
procedure in one depot wants to invoke a routine in another depot, that
have parameters/etc of some user-defined data type.  The expected most
common use case would be when there are 2 depot mounts, one being a
persistent database and the other being transient application-specific code
that creates or otherwise works with that persistent database.

=back

The default value of C<Federation> has zero depot mounts.

=head2 sys.std.Core.Type.Cat.DepotMountSet

A C<DepotMountSet> is a C<DHRelation> that specifies a set of depot
mounts, such that each tuple is a single depot mount.  A depot mount is a
named in-DBMS context by which a depot is referenced from either other
depots or by the main application, and it also specifies the catalog
content of the depot itself.

A C<DepotMountSet> has these 3 attributes:

=over

=item C<name> - C<Name>

This is the declared name of the depot mount; other Muldis D code would
reference it with this name.

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about this specific mount of the
depot.

=item C<depot> - C<Depot>

This defines the entire system catalog of the depot that this mount has
made visible to the DBMS.

=back

A C<DepotMountSet> has a unary primary key on the C<name> attribute.
Its default value is empty.

=head2 sys.std.Core.Type.Cat.FedTypeMapSet

A C<FedTypeMapSet> is a C<DHRelation> such that each tuple in it
specifies which of multiple depots have a copy of the same data type, for
the purpose of treating all the copies as being interchangeable, so to
support cross-depot interaction.

A C<FedTypeMapSet> has these 2 attributes:

=over

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about this type mapping.

=item C<types> - C<set_of.APTypeNC>

This lists the C<fed.>-qualified names of 0..N data types that are all
considered to be copies of the same 1 type, and should be treated
interchangeably by the DBMS.

=back

A C<FedTypeMapSet> has a primary key on the C<map> attribute.  Its
default value is empty.

=head1 TYPES FOR DEFINING DEPOTS AND SUBDEPOTS

=head2 sys.std.Core.Type.Cat.Depot

A C<Depot> is a C<Database>.  It specifies the entire system
catalog of a single depot, that is, the widest scope within which all
entities must be fully defined in terms of just user-defined entities
within the same scope or of system-defined entities.  It also doubles to
specify the system catalog of a subdepot, which is an arbitrary subset of a
depot's entities that internally looks like a depot; a depot can have 0..N
subdepots, and any that exist are arranged in a hierarchy with the depot as
the root.  The system catalog variable named C<nlx.cat> is of the C<Depot>
type.

A C<Depot> has these 18 attributes:

=over

=item C<scm_comment> - C<just_of.Comment>

This is an optional programmer comment about the [|sub]depot as a whole.

=item C<subdepots> - C<SubdepotSet>

These are all the subdepots that this system catalog contains (which might
be none).

=item C<functions|updaters|recipes|procedures> -
C<[Function|Updater|Recipe|Procedure]Set>

These are all the definitions that this [|sub]depot contains of functions,
updaters, recipes, procedures.

=item C<[scalar|tuple|relation|domain|subset|mixin]_types> -
C<[Scalar|Tuple|Relation|Domain|Subset|Mixin]TypeSet>

These are all the definitions that this [|sub]depot contains of scalar
types with possreps, complete tuple and relation types, domain types, and
subset types, and mixin types.

=item C<[|distrib_][key|subset]_constrs> -
C<[|Distrib][Key|Subset]ConstrSet>

These are all the definitions that this [|sub]depot contains of
|distributed key|subset constraints.

=item C<stim_resp_rules> - C<StimRespRuleSet>

These are all the definitions that this [|sub]depot contains of
stimulus-response rules.

=item C<data> - C<maybe_of.RPTypeNC>

This is the declared data type of the self-local dbvar that this
[|sub]depot contains, iff C<data> is a C<Just>; if C<data> is C<Nothing>
(the default), then this [|sub]depot does not have a self-local dbvar.

=back

There is a distributed binary primary key over the C<parent> plus C<name>
attributes of all 8 of a C<Depot>'s main C<DHRelation>-typed attributes.

The default value of C<Depot> defines an empty [|sub]depot
that does not have any self-local dbvar.

=head2 sys.std.Core.Type.Cat.SubdepotSet

A C<SubdepotSet> is a C<DHRelation> that specifies the set of subdepots
that a depot might optionally have for organizing its entities;
these subdepots are organized into a tree whose root is the depot.  A
C<SubdepotSet> only specifies that a subdepot exists, not which depot
entities it contains; see the C<Depot> which contains it for that.

A C<SubdepotSet> has these 4 attributes:

=over

=item C<parent> - C<NameChain>

This is the fully-qualified name, in the C<nlx.[cat|lib|data]> namespace
of any hypothetical immediate child namespace of the depot,
of the subdepot's parent subdepot, which is often just the depot itself.

=item C<name> - C<Name>

This is the declared name of the subdepot within the namespace defined by
C<parent>; other Muldis D code would reference it with the combination of
C<parent> and C<name>.

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about this specific subdepot as
associated with this subdepot name.

=item C<scm_vis_ord> - C<NNInt>

This is the visible order of this subdepot's declaration relative to all of
the named entities directly within the namespace defined by C<parent>.

=back

A C<SubdepotSet> has a binary primary key on the C<parent> plus
C<name> attributes.  Its default value is empty.

=head2 sys.std.Core.Type.Cat.[Function|Updater|Recipe|Procedure]Set

A C<[Function|Updater|Recipe|Procedure]Set> is a C<DHRelation> that
specifies a set of functions|updaters|recipes|procedures that a [|sub]depot
might directly contain.  I<TODO: each routine may be either public for the
DBMS as a whole or private to the subdepot.>

A C<[Function|Updater|Recipe|Procedure]Set> has these 5 attributes:

=over

=item C<parent> - C<NameChain>

This is the fully-qualified name, in the C<nlx.[cat|lib|data]> namespace of
any hypothetical immediate child namespace of the depot, of the
function|updater|recipe|procedure's parent [|sub]depot.

=item C<name> - C<Name>

This is the declared name of the function|updater|recipe|procedure within
the namespace defined by C<parent>; other Muldis D code would reference it
with the combination of C<parent> and C<name>.

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about the
function|updater|recipe|procedure as a whole.

=item C<scm_vis_ord> - C<NNInt>

This is the visible order of this routine's declaration relative to all of
the named entities directly within the namespace defined by C<parent>.

=item C<material> - C<Function|Updater|Recipe|Procedure>

This defines the entire function|updater|recipe|procedure sans its name.

=back

A C<[Function|Updater|Recipe|Procedure]Set> has a binary primary key on the
C<parent> plus C<name> attributes.  Its default value is empty.

=head2 sys.std.Core.Type.Cat.[Scalar|Tuple|Relation|Domain|Subset|Mixin]TypeSet

A C<[Scalar|Tuple|Relation|Domain|Subset|Mixin]TypeSet> is a C<DHRelation>
that specifies a set of scalar|tuple|relation|domain|subset|mixin types
that a [|sub]depot might directly contain.  I<TODO: each type may be either
public for the DBMS as a whole or private to the subdepot.>

A C<[Scalar|Tuple|Relation|Domain|Subset|Mixin]TypeSet> has these 5
attributes:

=over

=item C<parent> - C<NameChain>

This is the fully-qualified name, in the C<nlx.[cat|lib|data]> namespace
of any hypothetical immediate child namespace of the depot,
of the scalar|tuple|relation|domain|subset|mixin type's parent [|sub]depot.

=item C<name> - C<Name>

This is the declared name of the scalar|tuple|relation|domain|subset|mixin
type within the namespace defined by C<parent>; other Muldis D code would
reference it with the combination of C<parent> and C<name>.

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about the
scalar|tuple|relation|domain|subset|mixin type as a whole.

=item C<scm_vis_ord> - C<NNInt>

This is the visible order of this type's declaration relative to all of
the named entities directly within the namespace defined by C<parent>.

=item C<material> - C<[Scalar|Tuple|Relation|Domain|Subset|Mixin]Type>

This defines the entire scalar|tuple|relation|domain|subset|mixin type sans
its name.

=back

A C<[Scalar|Tuple|Relation|Domain|Subset|Mixin]TypeSet> has a binary
primary key on the C<parent> plus C<name> attributes.  Its default value is
empty.

=head2 sys.std.Core.Type.Cat.[|Distrib][Key|Subset]ConstrSet

A C<[|Distrib][Key|Subset]ConstrSet> is a C<DHRelation> that specifies a
set of |distributed key|subset constraints that a [|sub]depot might
directly contain.

A C<[|Distrib][Key|Subset]ConstrSet> has these 5 attributes:

=over

=item C<parent> - C<NameChain>

This is the fully-qualified name, in the C<nlx.[cat|lib|data]> namespace of
any hypothetical immediate child namespace of the depot, of the
|distributed key|subset constraint's parent [|sub]depot.

=item C<name> - C<Name>

This is the declared name of the |distributed key|subset constraint within
the namespace defined by C<parent>; other Muldis D code would reference it
with the combination of C<parent> and C<name>.

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about the |distributed key|subset
constraint as a whole.

=item C<scm_vis_ord> - C<NNInt>

This is the visible order of this constraint's declaration relative to all
of the named entities directly within the namespace defined by C<parent>.

=item C<material> - C<[|Distrib][Key|Subset]Constr>

This defines the entire |distributed key|subset constraint sans its name.

=back

A C<[|Distrib][Key|Subset]ConstrSet> has a binary primary key on the
C<parent> plus C<name> attributes.  Its default value is empty.

=head2 sys.std.Core.Type.Cat.StimRespRuleSet

A C<StimRespRuleSet> is a C<DHRelation> that specifies a set of
stimulus-response rules that a [|sub]depot might directly contain.

A C<StimRespRuleSet> has these 5 attributes:

=over

=item C<parent> - C<NameChain>

This is the fully-qualified name, in the C<nlx.[cat|lib|data]> namespace of
any hypothetical immediate child namespace of the depot, of the
stimulus-response rule's parent [|sub]depot.

=item C<name> - C<Name>

This is the declared name of the stimulus-response rule within the
namespace defined by C<parent>; other Muldis D code would reference it with
the combination of C<parent> and C<name>.

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about the stimulus-response rule as
a whole.

=item C<scm_vis_ord> - C<NNInt>

This is the visible order of this rule's declaration relative to all of
the named entities directly within the namespace defined by C<parent>.

=item C<material> - C<StimRespRule>

This defines the entire stimulus-response rule sans its name.

=back

A C<StimRespRuleSet> has a binary primary key on the C<parent> plus C<name>
attributes.  Its default value is empty.

=head1 TYPES FOR DEFINING ROUTINES

=head2 sys.std.Core.Type.Cat.Function

A C<Function> is a C<DHTuple>.  It defines a new function, which has 2
main parts, called I<heading> and I<body>:  The I<heading> defines the
function's entire public interface, which is all the details of how to use
it, except for its name, and no more detail than
necessary about how it is implemented.  The I<body> defines the function's
entire implementation (or the main body of a function), besides its
name/etc and what the I<heading> defines.  The function's name is
provided by the larger context that embeds the
C<Function>, which is either a C<Depot> or C<System>.  Every C<Function>
must have a specified I<heading>, but having a specified I<body> is
optional iff the C<Function> is embedded in a C<System>, because often the
implementations of system-defined routines are not defined in terms of
other Muldis D routines, but that the I<body> must not be specified if the
C<Function> is virtual.

A C<Function> has these 7 attributes, of which the 5 C<result_type>,
C<params>, C<opt_params>, C<dispatch_params>, C<implements> define the
I<heading> and the 1 C<expr> defines the I<body>:

=over

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about the function as a whole.

=item C<result_type> - C<RPTypeNC>

This is the declared result data type of the function as a whole.

=item C<params> - C<NameTypeMap>

This is the declared parameter list of the function, which has 0..N named
and typed parameters.

=item C<opt_params> - C<set_of.Name>

This indicates the subset of the function's parameters that are optional,
that is, do not need to be supplied explicit arguments when the function is
invoked; any function parameters not named here must be supplied explicit
arguments.  Any parameter marked as optional which is not given an explicit
argument will implicitly default to the default value of its declared type.
Each element of C<opt_params> must match a parameter name in C<params>.

=item C<dispatch_params> - C<set_of.Name>

Iff C<dispatch_params> is nonempty then this function is a virtual
function; otherwise, empty means not virtual.  A virtual function must
have no I<body> specified.  This attribute indicates the subset of the
function's parameters whose invocation arguments' types are consulted to
determine which other function, that explicitly implements this virtual
one, is automatically dispatched to.  Each element of C<dispatch_params>
must match a parameter name in C<params>.  Any given parameter can not be
both a dispatch parameter and an optional parameter.

=item C<implements> - C<set_of.RPFunctionNC>

Iff C<implements> is nonempty then this function is explicitly declaring
that it implements the other (typically just one), virtual functions named
by its elements; otherwise, empty means not implementing any virtuals.  An
implementing function must have the same parameter list as its virtuals,
save that the implementer's parameters' and result's declared types must be
subtypes of the corresponding ones of the virtuals.

=item C<expr> - C<ExprNodeSet>

This defines the value expression tree that comprises the entire
function body.

=back

Iff a C<Function> has no specified I<body>, then C<expr> must have zero
member nodes; otherwise, C<expr> must have at least 1 member node.

A C<Function> with a specified I<body>
specifies a simple value expression tree of named
expression nodes, each of which is a tuple of one of its C<expr.\w+_exprs>
attributes.  It must have at least 1 member node, and
all member nodes must define a
simple expression node tree, such that every member except one (which is
the root node) has one of its peers as a parent node, and no direct cycles
between members are permitted (only indirect cycles based on
function invocations are allowed); the name of the root node must be the
empty string.  Note that the composed-into function's parameters
are also implicitly tree nodes, and are referenced by name into the
expression the same way as any other named expression node is.  The
tree must denote a value
expression whose result type is of the result type of the function
it is composed into, and which invokes all of the function's parameters.

C<Function> has a distributed primary key over the C<name> attributes of
C<params> and the C<name> attributes of all the attributes of C<expr>.  Its
default value has zero parameters, a result type of C<Bool>, and has no
specified I<body>.

=head2 sys.std.Core.Type.Cat.NamedValFunc

A C<NamedValFunc> defines a C<named-value>, which is a kind of function.
C<NamedValFunc> is a proper subtype of C<Function> where all member values
declare a function that is nullary / has exactly zero parameters.  Its
default value is a function whose invocation unconditionally results in
C<Bool:False>.

=head2 sys.std.Core.Type.Cat.ValMapFunc

A C<ValMapFunc> defines a C<value-map>, which is a kind of function.
C<ValMapFunc> is a proper subtype of C<Function> where all member values
declare a function that has at least 1 parameter, and that 1 is named
C<topic>.  Its default value is the same as that of its C<ValMapUFunc>
subtype.

=head2 sys.std.Core.Type.Cat.ValMapUFunc

A C<ValMapUFunc> defines a C<value-map-unary>, which is a kind of
C<value-map>.  C<ValMapUFunc> is a proper subtype of C<ValMapFunc> where
all member values declare a function that is unary / has exactly one
parameter (just the C<topic> parameter).  Its default value is a function
whose invocation unconditionally results in its C<topic> argument and whose
only parameter has a declared type of C<Universal>.

=head2 sys.std.Core.Type.Cat.ValFiltFunc

A C<ValFiltFunc> defines a C<value-filter>, which is a kind of
C<value-map>.  C<ValFiltFunc> is a proper subtype of C<ValMapFunc> where
all member values declare a function whose result's declared type is
C<Bool>.  Its default value is the same as that of its C<ValConstrFunc>
subtype.

=head2 sys.std.Core.Type.Cat.ValConstrFunc

A C<ValConstrFunc> defines a C<value-constraint>, which is a kind of
C<value-filter> I<and> a kind of C<value-map-unary>.  C<ValConstrFunc> is
the intersection type of C<ValFiltFunc> and C<ValMapUFunc>.  Its default
value is a function whose invocation unconditionally results in
C<Bool:True> and whose only parameter has a declared type of C<Universal>.

=head2 sys.std.Core.Type.Cat.TransConstrFunc

A C<TransConstrFunc> defines a C<transition-constraint>, which is a kind of
function.  C<TransConstrFunc> is a proper subtype of C<Function> where all
member values declare a function that is binary / has exactly 2 parameters,
and those 2 are named C<before> and C<after>, and the declared types of
those 2 parameters are identical, and the declared type of the function's
result is C<Bool>.  Its default value is a function whose invocation
unconditionally results in C<Bool:True>.

=head2 sys.std.Core.Type.Cat.ValRedFunc

A C<ValRedFunc> defines a C<value-reduction>, which is a kind of function.
C<ValRedFunc> is a proper subtype of C<Function> where all member values
declare a function that has at least 2 parameters, and those 2 are named
C<v1> and C<v2>, and the declared types of those 2 parameters are
identical, and the declared type of the function's result is identical to
that of either of those 2 parameters.  Its default value is a function,
whose invocation unconditionally results in its C<v1> argument, and that
has exactly 2 parameters, and all 3 of its declared types are C<Universal>.

=head2 sys.std.Core.Type.Cat.OrdDetFunc

An C<OrdDetFunc> defines an C<order-determination>, which is a kind of
function.  C<OrdDetFunc> is a proper subtype of C<Function> where all
member values declare a function that has at least 3 parameters, and those
3 are named C<topic>, C<other> and C<is_reverse_order>, and the declared
types of C<topic> and C<other> are identical, and the declared type of
C<is_reverse_order> is C<Bool>, and the declared type of the function's
result is C<Order>.  Its default value is a function, whose C<topic> and
C<other> parameters both have the declared type of C<Bool>, which orders
C<Bool:False> before C<Bool:True>.

=head2 sys.std.Core.Type.Cat.ExprNodeSet

An C<ExprNodeSet> is a C<Database> that specifies a set of named value
expression nodes.  It is typically composed into a
function|updater|recipe.  Each tuple of an C<ExprNodeSet> attribute is a
named expression node, which is the majority component of functional Muldis
D code.  All arbitrarily complex Muldis D expression trees, including
relational queries, are composed of just expression nodes, either directly,
or indirectly by way of function invocations, as each function body is
itself composed entirely of a single expression tree (of at least 1 node).
Only functions and updaters and recipes may contain expression
nodes, so for any procedures that would conceptually include them, those
portions of the procedures need to be separated out and encapsulated by
named functions or updaters or recipes.  Note that, while the
general case has expression trees simply denoting a value, in some cases
they may instead define a pseudo-variable / virtual variable; that only
happens in updaters or recipes where the expression is used as an argument
for a subject-to-update parameter of an updater or recipe call; in
that case the leaf nodes / only node of the expression must map to a
subject-to-update parameter of the expression-containing updater or recipe.

An C<ExprNodeSet> has these 15 attributes:

=over

=item C<ovl_sca_val_exprs> - C<OVLScaValExprNodeSet>

These are expression nodes that represent scalar values of types such that
all of the standard Muldis D dialects provide special "opaque value
literal" syntax specific to the type.  These are expression nodes that
represent scalar value literals that are I<not> specified simply in terms
of possrep attributes.

=item C<sca_sel_exprs> - C<ScaSelExprNodeSet>

These are expression nodes that represent generic scalar value
selections specified just in terms of possrep attributes.

=item C<tup_sel_exprs> - C<TupSelExprNodeSet>

These are expression nodes that represent tuple value selections.

=item C<rel_sel_exprs> - C<RelSelExprNodeSet>

These are expression nodes that represent generic relation value
selections.

=item C<set_sel_exprs> - C<SetSelExprNodeSet>

These are expression nodes that represent set value selections.

=item C<ary_sel_exprs> - C<ArySelExprNodeSet>

These are expression nodes that represent array value selections.

=item C<bag_sel_exprs> - C<BagSelExprNodeSet>

These are expression nodes that represent bag value selections.

=item C<sp_ivl_sel_exprs> - C<SPIvlSelExprNodeSet>

These are expression nodes that represent single-piece interval value
selections.

=item C<mp_ivl_sel_exprs> - C<MPIvlSelExprNodeSet>

These are expression nodes that represent multi-piece interval value
selections.

=item C<list_sel_exprs> - C<ListSelExprNodeSet>

These are expression nodes that represent low-level list value selections.

=item C<acc_exprs> - C<AccExprNodeSet>

These are expression nodes that represent accessors of attributes of other,
tuple-valued expression nodes, or aliases of other expression nodes.

=item C<func_invo_exprs> - C<FuncInvoExprNodeSet>

These are expression nodes that represent function invocations.

=item C<if_else_exprs> - C<IfElseExprNodeSet>

These are expression nodes that represent if-else control flow expressions.

=item C<given_when_def_exprs> - C<GivenWhenDefExprNodeSet>

These are expression nodes that represent given-when-default control flow
expressions.

=item C<ap_material_nc_sel_exprs> - C<APMaterialNCSelExprNodeSet>

These are expression nodes that define routine or type reference literals.

=back

There is a distributed primary key over the C<name> attributes of all of an
C<ExprNodeSet>'s attributes.  Its default value is empty.

Note that, for each expression node in an C<ExprNodeSet>, iff the
expression node is declared directly within its host atomic routine's body,
then its C<scm_vis_ord> attribute is non-zero, and the latter gives the
node's visible order relative to all other such expression nodes, and all
update statements if applicable, of the host routine, and all update
statements of said host routine; otherwise, iff the expression node is
nested beneath another expression node or a statement node, then the
C<scm_vis_ord> attribute isn't applicable, and is zero.  In other words,
when generating concrete Muldis D code from a C<Function|Updater|Recipe>,
the sole determinant of whether to nest any given expression node under
another expression or statement node, or not, is based on whether its
C<scm_vis_ord> is zero or not; zero means nested, non-zero means otherwise.

=head2 sys.std.Core.Type.Cat.OVLScaValExprNodeSet

An C<OVLScaValExprNodeSet> is a C<DHRelation> that specifies a set of value
expression nodes where each node is a hard-coded scalar literal that is
I<not> being specified explicitly in terms of possrep attributes, but
rather is specified using special "opaque value literal" syntax that all
of the Muldis D standard dialects provide.

An C<OVLScaValExprNodeSet> has these 4 attributes:

=over

=item C<name> - C<Name>

This is the declared name of the expression node.

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about the expression (leaf) node.

=item C<scm_vis_ord> - C<NNInt>

This is the visible order, if applicable, of this non-nested expression
node relative to all of its sibling such expression nodes, or statements.

=item C<value> - C<OVLScalar>

This is the actual scalar value that the expression node represents.

=back

An C<OVLScaValExprNodeSet> has a unary primary key on the C<name>
attribute.  Its default value is empty.

=head2 sys.std.Core.Type.Cat.ScaSelExprNodeSet

A C<ScaSelExprNodeSet> is a C<DHRelation> that specifies a set of value
expression nodes where each node represents a scalar value
selection that is specified explicitly in terms of possrep attributes.
This node kind may be used for values of absolutely any scalar type at all,
including all system-defined types, except for values of C<Int>
and C<String>, although
optimized Muldis D code will likely use C<OVLScaValExprNodeSet> where it
can do so instead of C<ScaSelExprNodeSet>.

A C<ScaSelExprNodeSet> has these 6 attributes:

=over

=item C<name> - C<Name>

This is the declared name of the expression node.

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about either the expression node or
the expression node (sub-)tree it is the root of.

=item C<scm_vis_ord> - C<NNInt>

This is the visible order, if applicable, of this non-nested expression
node relative to all of its sibling such expression nodes, or statements.

=item C<type_name> - C<RPTypeNC>

This is the name of the type that the scalar value belongs to.

=item C<possrep_name> - C<Name>

This is the name of the possrep, of the type named by C<type_name>, in
terms of whose attributes the scalar value is being selected.

=item C<possrep_attrs> - C<NameExprMap>

These represent the attributes (names and values) of the C<possrep_name>
possrep of the scalar value being selected.

=back

A C<ScaSelExprNodeSet> has a unary primary key on the C<name>
attribute.  Its default value is empty.

=head2 sys.std.Core.Type.Cat.TupSelExprNodeSet

A C<TupSelExprNodeSet> is a C<DHRelation> that specifies a set of value
expression nodes where each node represents a tuple value selection.

A C<TupSelExprNodeSet> has these 4 attributes:

=over

=item C<name> - C<Name>

This is the declared name of the expression node.

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about either the expression node or
the expression node (sub-)tree it is the root of.

=item C<scm_vis_ord> - C<NNInt>

This is the visible order, if applicable, of this non-nested expression
node relative to all of its sibling such expression nodes, or statements.

=item C<attrs> - C<NameExprMap>

These represent the attributes (names and values) of the tuple
value being selected.

=back

A C<TupSelExprNodeSet> has a unary primary key on the C<name>
attribute.  Its default value is empty.

=head2 sys.std.Core.Type.Cat.RelSelExprNodeSet

A C<RelSelExprNodeSet> is a C<DHRelation> that specifies a set of value
expression nodes where each node represents a relation value selection.

A C<RelSelExprNodeSet> has these 5 attributes:

=over

=item C<name> - C<Name>

This is the declared name of the expression node.

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about either the expression node or
the expression node (sub-)tree it is the root of.

=item C<scm_vis_ord> - C<NNInt>

This is the visible order, if applicable, of this non-nested expression
node relative to all of its sibling such expression nodes, or statements.

=item C<head> - C<set_of.Name>

These are the names of all of this relation value's attributes.

=item C<body> - C<set_of.NameExprMap>

These represent the tuples of the relation value being
selected.  When this value expression is evaluated, if any child expression
nodes are such that any duplicate tuples might be input to this
C<RelSelExprNodeSet> selector, the duplicates are silently eliminated and
do not constitute a failure condition.

=back

A C<RelSelExprNodeSet> has a unary primary key on the C<name>
attribute.  Its default value is empty.

=head2 sys.std.Core.Type.Cat.SetSelExprNodeSet

A C<SetSelExprNodeSet> is a C<DHRelation> that specifies a set of value
expression nodes where each node represents a set value selection.

A C<SetSelExprNodeSet> has these 4 attributes:

=over

=item C<name> - C<Name>

This is the declared name of the expression node.

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about either the expression node or
the expression node (sub-)tree it is the root of.

=item C<scm_vis_ord> - C<NNInt>

This is the visible order, if applicable, of this non-nested expression
node relative to all of its sibling such expression nodes, or statements.

=item C<elems> - C<set_of.Name>

These represent the elements of the set value being selected.
When this value expression is evaluated, if any child expression nodes are
such that any duplicate tuples might be input to this C<SetSelExprNodeSet>
selector, the duplicates are silently eliminated and do not constitute a
failure condition.

=back

A C<SetSelExprNodeSet> has a unary primary key on the C<name>
attribute.  Its default value is empty.

=head2 sys.std.Core.Type.Cat.ArySelExprNodeSet

An C<ArySelExprNodeSet> is a C<DHRelation> that specifies a set of value
expression nodes where each node represents an array value selection.

An C<ArySelExprNodeSet> has these 4 attributes:

=over

=item C<name> - C<Name>

This is the declared name of the expression node.

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about either the expression node or
the expression node (sub-)tree it is the root of.

=item C<scm_vis_ord> - C<NNInt>

This is the visible order, if applicable, of this non-nested expression
node relative to all of its sibling such expression nodes, or statements.

=item C<elems> - C<array_of.Name>

These represent the elements of the array value being selected.

=back

An C<ArySelExprNodeSet> has a unary primary key on the C<name>
attribute.  Its default value is empty.

=head2 sys.std.Core.Type.Cat.BagSelExprNodeSet

A C<BagSelExprNodeSet> is a C<DHRelation> that specifies a set of value
expression nodes where each node represents a bag value selection.

A C<BagSelExprNodeSet> has these 4 attributes:

=over

=item C<name> - C<Name>

This is the declared name of the expression node.

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about either the expression node or
the expression node (sub-)tree it is the root of.

=item C<scm_vis_ord> - C<NNInt>

This is the visible order, if applicable, of this non-nested expression
node relative to all of its sibling such expression nodes, or statements.

=item C<elems> - C<bag_of.Name>

These represent the elements of the bag value being selected.
When this value expression is evaluated, if any child expression nodes are
such that any tuple pairs with duplicate C<value> attribute values might be
input to this C<BagSelExprNodeSet> selector, the tuple pairs are silently
merged as per the semantics of bag union; the replacement tuple for such a
pair has a C<count> attribute that is the sum of that attribute of each of
the originals in said pair; any duplicate C<value> do not constitute a
failure condition.

Note that, because of how C<BagSelExprNodeSet> is defined, the C<count>
attribute value of each C<elems> tuple is a compile time constant, since an
integer is stored in the system catalog rather than the name of an
expression node like with C<value>; if you actually want the bag value
being selected at runtime to have runtime-determined C<count> values, then
you must use a C<RelSelExprNodeSet> rather than a C<BagSelExprNodeSet>.

=back

A C<BagSelExprNodeSet> has a unary primary key on the C<name>
attribute.  Its default value is empty.

=head2 sys.std.Core.Type.Cat.SPIvlSelExprNodeSet

An C<SPIvlSelExprNodeSet> is a C<DHRelation> that specifies a set of value
expression nodes where each node represents a single-piece interval value
selection.

An C<SPIvlSelExprNodeSet> has these 4 attributes:

=over

=item C<name> - C<Name>

This is the declared name of the expression node.

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about either the expression node or
the expression node (sub-)tree it is the root of.

=item C<scm_vis_ord> - C<NNInt>

This is the visible order, if applicable, of this non-nested expression
node relative to all of its sibling such expression nodes, or statements.

=item C<interval> - C<sp_interval_of.Name>

These represent the attributes of the single-piece interval value being
selected.

Note that, because of how C<SPIvlSelExprNodeSet> is defined, the
C<excludes_[min|max]> attribute values of the single-piece interval are
compile time constants, since a boolean is stored in the system catalog for
each rather than the name of an expression node like with the C<min> and
C<max> attributes; if you actually want the single-piece interval value
being selected at runtime to have runtime-determined C<excludes_[min|max]>
attribute values, then you must use a C<TupSelExprNodeSet> rather than an
C<SPIvlSelExprNodeSet>.

=back

An C<SPIvlSelExprNodeSet> has a unary primary key on the C<name> attribute.
Its default value is empty.

=head2 sys.std.Core.Type.Cat.MPIvlSelExprNodeSet

An C<MPIvlSelExprNodeSet> is a C<DHRelation> that specifies a set of value
expression nodes where each node represents a multi-piece interval value
selection.

An C<MPIvlSelExprNodeSet> has these 4 attributes:

=over

=item C<name> - C<Name>

This is the declared name of the expression node.

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about either the expression node or
the expression node (sub-)tree it is the root of.

=item C<scm_vis_ord> - C<NNInt>

This is the visible order, if applicable, of this non-nested expression
node relative to all of its sibling such expression nodes, or statements.

=item C<elems> - C<mp_interval_of.Name>

These represent the elements, each of which is a single-piece interval, of
the multi-piece interval value being selected.  When this value expression
is evaluated, if any child expression nodes are such that any duplicate
tuples might be input to this C<MPIvlSelExprNodeSet> selector, the
duplicates are silently eliminated and do not constitute a failure
condition.

Note that, because of how C<MPIvlSelExprNodeSet> is defined, the
C<excludes_[min|max]> attribute values of the multi-piece interval are
compile time constants, since a boolean is stored in the system catalog for
each rather than the name of an expression node like with the C<min> and
C<max> attributes; if you actually want the multi-piece interval value
being selected at runtime to have runtime-determined C<excludes_[min|max]>
attribute values, then you must use a C<RelSelExprNodeSet> rather than an
C<MPIvlSelExprNodeSet>.

=back

An C<MPIvlSelExprNodeSet> has a unary primary key on the C<name> attribute.
Its default value is empty.

=head2 sys.std.Core.Type.Cat.ListSelExprNodeSet

An C<ListSelExprNodeSet> is a C<DHRelation> that specifies a set of value
expression nodes where each node represents a low-level list value
selection.

An C<ListSelExprNodeSet> has these 4 attributes:

=over

=item C<name> - C<Name>

This is the declared name of the expression node.

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about either the expression node or
the expression node (sub-)tree it is the root of.

=item C<scm_vis_ord> - C<NNInt>

This is the visible order, if applicable, of this non-nested expression
node relative to all of its sibling such expression nodes, or statements.

=item C<elems> - C<array_of.Name>

These represent the elements of the low-level list value being selected.

=back

An C<ListSelExprNodeSet> has a unary primary key on the C<name>
attribute.  Its default value is empty.

=head2 sys.std.Core.Type.Cat.AccExprNodeSet

An C<AccExprNodeSet> is a C<DHRelation> that specifies a set of value
expression nodes where each node is an accessor or alias for an attribute
of another, tuple-valued expression node, or is simply an alias for another
expression node, defined in terms of a C<NameChain>.

An C<AccExprNodeSet> has these 4 attributes:

=over

=item C<name> - C<Name>

This is the declared name of the expression node.

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about the expression (leaf) node.

=item C<scm_vis_ord> - C<NNInt>

This is the visible order, if applicable, of this non-nested expression
node relative to all of its sibling such expression nodes, or statements.

=item C<target> - C<NameChain>

This is the fully-qualified invocation name of the expression node, or
attribute thereof if it is tuple-valued, being accessed or aliased.

=back

An C<AccExprNodeSet> has a unary primary key on the C<name>
attribute.  Its default value is empty.

=head2 sys.std.Core.Type.Cat.FuncInvoExprNodeSet

A C<FuncInvoExprNodeSet> is a C<DHRelation> that specifies a set of value
expression nodes where each node represents the result of invoking a named
function with specific arguments.

A C<FuncInvoExprNodeSet> has these 5 attributes:

=over

=item C<name> - C<Name>

This is the declared name of the expression node.

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about either the expression node or
the expression node (sub-)tree it is the root of.

=item C<scm_vis_ord> - C<NNInt>

This is the visible order, if applicable, of this non-nested expression
node relative to all of its sibling such expression nodes, or statements.

=item C<function> - C<MaterialNC>

This is the name of the function being invoked.

=item C<args> - C<NameExprMap>

These are the arguments for the function invocation.  Each element
defines one argument value, with the element C<name> matching the invoked
function's parameter name, and the element C<expr> naming another
local expression node (or parameter) which defines the value.

=back

A C<FuncInvoExprNodeSet> has a unary primary key on the C<name>
attribute.  Its default value is empty.

=head2 sys.std.Core.Type.Cat.IfElseExprNodeSet

An C<IfElseExprNodeSet> is a C<DHRelation> that specifies a set of value
expression nodes where each node represents an N-way if-else control flow
expression.

The reason that the C<IfElseExprNodeSet> expression node kind exists,
rather than this functionality being provided by an ordinary function
invocation, is because the semantics of an if-else expression require its
sub-expressions to be evaluated in a specific sequence and that later
elements in the sequence are evaluated only conditionally based on the
results of earlier elements in the sequence, whereas with ordinary
functions the operands are all independent of each other, can be done in
any order, and can all be evaluated prior to the function.  The main
scenario that requires the special semantics is when an earlier conditional
part of the sequence is testing whether it is even logically possible to
evaluate a later part of the sequence; for example, the first condition may
test if a value is a member of a certain data type, and a later part of the
sequence may want to use some operator on the value that is only defined
for the certain data type (invoking it on something else would result in a
failure/exception); so only known-safe/appropriate expressions then get
evaluated.

An C<IfElseExprNodeSet> has these 5 attributes:

=over

=item C<name> - C<Name>

This is the declared name of the expression node.

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about either the expression node or
the expression node (sub-)tree it is the root of.

=item C<scm_vis_ord> - C<NNInt>

This is the visible order, if applicable, of this non-nested expression
node relative to all of its sibling such expression nodes, or statements.

=item C<if_then> - C<array_of.IfThenExprMap>

This is a sequence of 0..N conditional expressions, each of which has an
associated result expression.  Each conditional expression will evaluate in
order while the previous conditional resulted in C<Bool:False>; once a
conditional results in C<Bool:True>, its associated result expression will
evaluate and be the result of the larger if-else sequence, and no more
conditionals will be evaluated; no result expressions will be evaluated
except the one with the true conditional.

=item C<else> - C<Name>

Iff none of the conditionals in C<if_then> result in C<Bool:True> (or as a
trivial case, if C<if_then> is an empty sequence), then the result
expression represented by the local expression node (or parameter) named by
C<else> will be evaluated, and be the result of the larger if-else.

=back

An C<IfElseExprNodeSet> has a unary primary key on the C<name>
attribute.  Its default value is empty.

=head2 sys.std.Core.Type.Cat.IfThenExprMap

An C<IfThenExprMap> is a C<DHTuple>.  It defines an element of an if-else
sequential expression.  An C<IfThenExprMap> has 2 attributes, C<if> and
C<then>, each of which is a C<Name>; C<if> has the name of a local
expression node (or parameter), and C<then> has likewise.  The C<if> node
is the condition to evaluate; if that condition evaluates to C<Bool:True>,
then the C<then> node is evaluated and its result is the result of the
whole if-else expression; otherwise, C<then> is not evaluated.  Its default
value has the default value of the C<Name> type in both attributes.

=head2 sys.std.Core.Type.Cat.GivenWhenDefExprNodeSet

A C<GivenWhenDefExprNodeSet> is a C<DHRelation> that specifies a set of
value expression nodes where each node represents an N-way
given-when-default switch control flow expression that dispatches based
on matching a single value with several options.

A C<GivenWhenDefExprNodeSet> is essentially a more specialized version
of an C<IfElseExprNodeSet> where every condition expression is a simple
value equality test and one of the operands is the same for all the
conditions in the set; also, with a given-when-default it doesn't matter
what order the conditionals are tested to find a true resulting one.

A C<GivenWhenDefExprNodeSet> has these 6 attributes:

=over

=item C<name> - C<Name>

This is the declared name of the expression node.

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about either the expression node or
the expression node (sub-)tree it is the root of.

=item C<scm_vis_ord> - C<NNInt>

This is the visible order, if applicable, of this non-nested expression
node relative to all of its sibling such expression nodes, or statements.

=item C<given> - C<Name>

This is the single operand value that is common to all the conditions; it
is the control value for the expression.

=item C<when_then> - C<WhenThenExprMap>

This is a set of distinct condition operand values, each of which has an
associated result expression.  If a condition operand matches the value of
C<given>, its associated result expression will evaluate and be the result
of the larger if-else sequence; no result expressions will be evaluated
except the one with the matching conditional operand.

=item C<default> - C<Name>

Iff none of the condition operand values in C<when_then> matches the value
of C<given> (or as a trivial case, if C<when_then> has no tuples), then the
result expression represented by the local expression node (or parameter)
named by C<default> will be evaluated, and be the result of the larger
given-when-default.

=back

A C<GivenWhenDefExprNodeSet> has a unary primary key on the C<name>
attribute.  Its default value is empty.

=head2 sys.std.Core.Type.Cat.WhenThenExprMap

A C<WhenThenExprMap> is a C<DHRelation>.  It defines a set of dispatch
options for a given-when-default expression.  A C<WhenThenExprMap> has 2
attributes, C<when> and C<then>, each of which is a C<Name>; C<when> has
the name of a local expression node (or parameter), and C<then> has
likewise.  The C<when> node is the not-common / distinct operand for each
condition.  If a C<when> value is matched, then the C<then> node is
evaluated and its result is the result of the whole g-w-d expression;
otherwise, C<then> is not evaluated.  Its default value has zero tuples.

=head2 sys.std.Core.Type.Cat.APMaterialNCSelExprNodeSet

An C<APMaterialNCSelExprNodeSet> is a C<DHRelation> that specifies a set of
expression nodes where each node represents a value of the
C<sys.std.Core.Type.Cat.AbsPathMaterialNC> type, which is selected in terms
of a value of the C<sys.std.Core.Type.Cat.RelPathMaterialNC> type.

The reason that the C<APMaterialNCSelExprNodeSet> expression node kind
exists, rather than the functionality of mapping relative paths to absolute
paths being provided by an ordinary unary function invocation, is because
the semantics of the operation depend on the location of the referencing
code, not just on the explicit parameters of the operation.  Moreover,
conceptually this mapping operation can be performed at compile time (of
the system catalog of a depot mount into native machine code) so at normal
runtime it is as if the absolute-path value was what was originally a value
literal in the source code.

An C<APMaterialNCSelExprNodeSet> has these 4 attributes:

=over

=item C<name> - C<Name>

This is the declared name of the expression node.

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about the expression (leaf) node.

=item C<scm_vis_ord> - C<NNInt>

This is the visible order, if applicable, of this non-nested expression
node relative to all of its sibling such expression nodes, or statements.

=item C<referencing> - C<RelPathMaterialNC>

This is the name, from the point of view of the routine embedding this
expression node, of the routine or type that the new C<AbsPathMaterialNC>
value is supposed to facilitate portable invoking of.

=back

An C<APMaterialNCSelExprNodeSet> has a unary (unique) key on the C<name>
attribute, plus another such key on the C<referencing> attribute.  Its
default value is empty.

=head2 sys.std.Core.Type.Cat.Updater

An C<Updater> is a C<DHTuple>.  It defines a new updater, which has 2
main parts, called I<heading> and I<body>:  The I<heading> defines the
updater's entire public interface, which is all the details of how to use
it, except for its name, and no more detail than
necessary about how it is implemented.  The I<body> defines the updater's
entire implementation (or the main body of an updater), besides its
name/etc and what the I<heading> defines.  The updater's name is
provided by the larger context that embeds the
C<Updater>, which is either a C<Depot> or C<System>.  Every C<Updater>
must have a specified I<heading>, but having a specified I<body> is
optional iff the C<Updater> is embedded in a C<System>, because often the
implementations of system-defined routines are not defined in terms of
other Muldis D routines, but that the I<body> must not be specified if the
C<Updater> is virtual.

An C<Updater> has these 8 attributes, of which the 5 C<upd_params>,
C<ro_params>, C<opt_params>, C<dispatch_params>, C<implements> define the
I<heading> and the 2 C<exprs>, C<stmt> define the I<body>:

=over

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about the updater as a whole.

=item C<upd_params> - C<NameTypeMap>

This is the declared subject-to-update parameter list of the updater, which
has 1..N named and typed such parameters.  It must have at least 1 element.

=item C<ro_params> - C<NameTypeMap>

This is the declared read-only parameter list of the updater, which has
0..N named and typed such parameters.

=item C<opt_params> - C<set_of.Name>

This indicates the subset of the updater's subject-to-update or read-only
parameters that are optional, that is, do not need to be supplied explicit
arguments when the function is invoked; any updater parameters not named
here must be supplied explicit arguments.  Any parameter marked as optional
which is not given an explicit argument will implicitly default to the
default value of its declared type; any subject-to-update parameter marked
as optional which is not given an explicit argument will implicitly bind to
a new anonymous variable (with the aforementioned default value) which is
discarded after the updater finishes executing.  Each element of
C<opt_params> must match a parameter name in either C<upd_params> or
C<ro_params>.

=item C<dispatch_params> - C<set_of.Name>

Iff C<dispatch_params> is nonempty then this updater is a virtual
updater; otherwise, empty means not virtual.  A virtual updater must
have no I<body> specified.  This attribute indicates the subset of the
updater's parameters whose invocation arguments' types are consulted to
determine which other updater, that explicitly implements this virtual
one, is automatically dispatched to.  Each element of C<dispatch_params>
must match a parameter name in C<upd_params> or C<ro_params>.  Any given
parameter can not be both a dispatch parameter and an optional parameter.

=item C<implements> - C<set_of.RPImperativeNC>

Iff C<implements> is nonempty then this updater is explicitly declaring
that it implements the other (typically just one), virtual updaters named
by its elements; otherwise, empty means not implementing any virtuals.  An
implementing updater must have the same parameter list as its virtuals,
save that the implementer's parameters' declared types must be
subtypes of the corresponding ones of the virtuals.

=item C<exprs> - C<ExprNodeSet>

This defines the expression trees that are arguments to the update
operators that C<stmt> invokes.  These expression trees must reference all
of the read-only parameters that the update operator has.

=item C<stmt> - C<MultiUpdStmt>

This defines the entire body of the updater, which is composed of
a single multi-update statement.  This multi-update statement must
reference all of the parameters that the updater has.

=back

Iff an C<Updater> has no specified I<body>, then C<exprs> must have zero
member nodes and C<stmt> must have zero member tuples; otherwise, C<stmt>
must have at least 1 member tuple.

C<Updater> has a distributed primary key over the C<name> attributes of
C<upd_params> and C<ro_params> and the C<name> attributes of all the
attributes of C<exprs>.  Its default value has 1 subject-to-update,
non-optional parameter whose name is C<topic> and whose declared type is
C<Bool>; it has zero read-only parameters; it has no specified I<body>.

=head2 sys.std.Core.Type.Cat.MultiUpdStmt

A C<MultiUpdStmt> is a C<DHRelation> that specifies a multi-update
statement (of 1..N variables), which is the narrowest scope implicitly
atomic component of procedural Muldis D code.  It is the most fundamental
component of procedural Muldis D code.  The variables being updated are
accessed via the host updater's or recipe's subject-to-update parameters
(or via the host updater's lexical-alias variables).  All
arbitrarily complex Muldis D value assignments, including relational
assignments, are composed of just C<MultiUpdStmt>, either directly, or
indirectly by way of updater or recipe invocations, as each updater and
recipe body is itself composed entirely of 1 multi-update statement (plus
supporting value expressions).  Only updaters and recipes may contain
C<MultiUpdStmt>, so for any procedures that would conceptually include
them, those portions of the procedures need to be separated out and
encapsulated by named updaters or recipes.  Each tuple of a multi-update
statement is a single update statement, which represents a single
invocation of an updater or recipe.  C<MultiUpdStmt> itself has no
restriction on the number of tuples it consists of, but:  At least 1 tuple
is required iff the multi-update statement is composed into a specified
updater or recipe body; otherwise there must be only be zero tuples for an
unspecified updater or recipe body.

A C<MultiUpdStmt> has these 5 attributes:

=over

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about the single update statement as
a whole.

=item C<scm_vis_ord> - C<NNInt>

This is the visible order of this single update statement relative to all
of its sibling statements, or non-nested expression nodes, of its host
updater's or recipe's multi-update statement.

=item C<imperative> - C<MaterialNC>

This is the name of the updater or recipe being invoked.

=item C<upd_args> - C<NameExprMap>

These are the 1..N subject-to-update arguments to the updater
invocation, or the 0..N subject-to-update arguments to the recipe
invocation, as-per C<ro_args>.  But since each expression tree in
C<upd_args> is binding to a subject-to-update parameter, the expression
tree actually is defining a pseudo-variable / virtual-variable over 1..N
statement-containing-updater subject-to-update parameters; in the most
trivial (and common) case, the parameter is referenced directly.

=item C<ro_args> - C<NameExprMap>

These are the 0..N read-only arguments to the updater or recipe invocation.
Each element defines one argument value, with the element C<name> matching
the invoked routine's parameter name, and the element C<expr> naming a
local expression node (or parameter) which defines the value.

=back

C<MultiUpdStmt> has a distributed primary key over the C<name>
attributes of C<upd_args> and C<ro_args>.  Its default value is empty.

=head2 sys.std.Core.Type.Cat.Recipe

A C<Recipe> is a C<DHTuple>.  It defines a new recipe, which has 2 main
parts, called I<heading> and I<body>:  The I<heading> defines the recipe's
entire public interface, which is all the details of how to use it, except
for its name, and no more detail than necessary about how it is
implemented.  The I<body> defines the recipe's entire implementation (or
the main body of an recipe), besides its name/etc and what the I<heading>
defines.  The recipe's name is provided by the larger context that embeds
the C<Recipe>, which is either a C<Depot> or C<System>.  Every C<Recipe>
must have a specified I<heading>, but having a specified I<body> is
optional iff the C<Recipe> is embedded in a C<System>, because often the
implementations of system-defined routines are not defined in terms of
other Muldis D routines, but that the I<body> must not be specified if the
C<Recipe> is virtual.

A C<Recipe> has these 10 attributes, of which the 7 C<upd_params>,
C<ro_params>, C<opt_params>, C<upd_global_params>, C<ro_global_params>
C<dispatch_params>, C<implements>, define the I<heading> and the 2
C<exprs>, C<stmt> define the I<body>:

=over

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about the recipe as a whole.

=item C<upd_params> - C<NameTypeMap>

This is the declared subject-to-update parameter list of the recipe, which
has 0..N named and typed such parameters.

=item C<ro_params> - C<NameTypeMap>

This is the declared read-only parameter list of the recipe, which has
0..N named and typed such parameters.

=item C<opt_params> - C<set_of.Name>

This is as per the same-named attribute of C<Updater>.

=item C<upd_global_params> - C<RcpGlobalVarAliasMap>

This declares 0..N lexical aliases for global variables which will
serve as implicit subject-to-update parameters of the recipe.

=item C<ro_global_params> - C<RcpGlobalVarAliasMap>

This declares 0..N lexical aliases for global variables which will
serve as implicit read-only parameters of the recipe.

=item C<dispatch_params> - C<set_of.Name>

Iff C<dispatch_params> is nonempty then this recipe is a virtual
recipe; otherwise, empty means not virtual.  A virtual recipe must
have no I<body> specified.  This attribute indicates the subset of the
recipe's parameters whose invocation arguments' types are consulted to
determine which other recipe, that explicitly implements this virtual
one, is automatically dispatched to.  Each element of C<dispatch_params>
must match a parameter name in C<upd_params> or C<ro_params>.  Any given
parameter can not be both a dispatch parameter and an optional parameter.

=item C<implements> - C<set_of.RPImperativeNC>

Iff C<implements> is nonempty then this recipe is explicitly declaring
that it implements the other (typically just one), virtual recipes named
by its elements; otherwise, empty means not implementing any virtuals.  An
implementing recipe must have the same parameter list as its virtuals,
save that the implementer's parameters' declared types must be
subtypes of the corresponding ones of the virtuals.

=item C<exprs> - C<ExprNodeSet>

This defines the expression trees that are arguments to the update
operators that C<stmt> invokes.  These expression trees must reference all
of the read-only parameters that the update operator has.

=item C<stmt> - C<MultiUpdStmt>

This defines the entire body of the recipe, which is composed of
a single multi-update statement.  This multi-update statement must
reference all of the parameters and global-aliases that the recipe has.

=back

Iff an C<Recipe> has no specified I<body>, then C<exprs> must have zero
member nodes and C<stmt> must have zero member tuples; otherwise, C<stmt>
must have at least 1 member tuple.

C<Recipe> must have at least one subject-to-update parameter or
subject-to-update lexical-alias variable.

C<Recipe> has a distributed primary key over the C<name> attributes of
C<upd_params> and C<ro_params> and C<upd_global_params> and
C<ro_global_params> and the
C<name> attributes of all the attributes of C<exprs>.  Its default value
has zero parameters and has no specified I<body>.

=head2 sys.std.Core.Type.Cat.RcpGlobalVarAliasMap

A C<RcpGlobalVarAliasMap> is a C<DHRelation>.  It defines a set of lexical
variable names, with a declared global variable for each.  It is used to
define lexical variables of recipes that are aliases for global variables,
for reading or updating.  A C<RcpGlobalVarAliasMap> has 4 attributes,
C<name> (a C<Name>), C<global> (a C<DataNC>), C<scm_comment> (a
C<Comment>), and C<scm_vis_ord> (a C<NNInt>); the C<name> is the name of
the lexical alias, and comprises a unary key; the C<global> is the
invocation name of the global variable.  Its default value has zero tuples.

=head2 sys.std.Core.Type.Cat.Procedure

A C<Procedure> is a C<DHTuple>.  It defines a new procedure, which has 2
main parts, called I<heading> and I<body>:  The I<heading> defines the
procedure's entire public interface, which is all the details of how to use
it, except for its name, and no more detail than
necessary about how it is implemented.  The I<body> defines the procedure's
entire implementation (or the main body of a procedure), besides its
name/etc and what the I<heading> defines.  The procedure's name is
provided by the larger context that embeds the
C<Procedure>, which is either a C<Depot> or C<System>.  Every C<Procedure>
must have a specified I<heading>, but having a specified I<body> is
optional iff the C<Procedure> is embedded in a C<System>, because often the
implementations of system-defined routines are not defined in terms of
other Muldis D routines, but that the I<body> must not be specified if the
C<Procedure> is virtual.

A C<Procedure> has these 10 attributes, of which the 7 C<upd_params>,
C<ro_params>, C<opt_params>, C<dispatch_params>, C<implements>,
C<is_system_service>, C<is_transaction> define the
I<heading> and the 2 C<vars>, C<stmt> define the I<body>:

=over

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about the procedure as a whole.

=item C<upd_params> - C<NameTypeMap>

This is the declared subject-to-update parameter list of the procedure,
which has 0..N named and typed such parameters.

=item C<ro_params> - C<NameTypeMap>

This is the declared read-only parameter list of the procedure, which has
0..N named and typed such parameters.

=item C<opt_params> - C<set_of.Name>

This is as per the same-named attribute of C<Updater>.

=item C<dispatch_params> - C<set_of.Name>

Iff C<dispatch_params> is nonempty then this procedure is a virtual
procedure; otherwise, empty means not virtual.  A virtual procedure must
have no I<body> specified.  This attribute indicates the subset of the
procedure's parameters whose invocation arguments' types are consulted to
determine which other procedure, that explicitly implements this virtual
one, is automatically dispatched to.  Each element of C<dispatch_params>
must match a parameter name in C<upd_params> or C<ro_params>.  Any given
parameter can not be both a dispatch parameter and an optional parameter.

=item C<implements> - C<set_of.RPImperativeNC>

Iff C<implements> is nonempty then this procedure is explicitly declaring
that it implements the other (typically just one), virtual procedures named
by its elements; otherwise, empty means not implementing any virtuals.  An
implementing procedure must have the same parameter list as its virtuals,
save that the implementer's parameters' declared types must be
subtypes of the corresponding ones of the virtuals.

=item C<is_system_service> - C<Bool>

Iff this is C<Bool:True> then the procedure is explicitly declared to be a
C<system-service>, meaning it will be subject to tighter constraints on its
allowed actions (it may not invoke any recipes / globals) and its execution
will automatically be entirely contained within a single transaction of the
highest possible isolation level, "serializable", same as an recipe is;
iff this is C<Bool:False> then the procedure is I<not> explicitly declared
to be a C<system-service>, and the other restrictions or automatic wrapper
transaction won't be present for supporting a C<system-service>.

=item C<is_transaction> - C<Bool>

If this is C<Bool:True> then the procedure constitutes an explicit (main or
child) transaction of its own; the transaction will commit if the procedure
completes its execution normally and it will roll back if the procedure
completes abnormally by throwing an exception; if this is C<Bool:False>
then the procedure does I<not> constitute its own transaction.  Note that a
procedure's C<is_transaction> must be C<Bool:True> if its
C<is_system_service> is C<Bool:True>; otherwise,
C<is_transaction> may be either C<Bool:True> or C<Bool:False>.

=item C<vars> - C<NameTypeMap>

This defines the 0..N (non-parameter) lexical variables of the
procedure; they initialize to the default values of their declared types.

=item C<stmt> - C<StmtNodeSet>

This defines the statement tree that comprises the entire procedure body.

=back

Iff a C<Procedure> has no specified I<body>, then C<stmt> must have zero
member nodes and C<vars> must have zero member tuples; otherwise, C<stmt>
must have at least 1 member node, which is a compound statement node
(having just that 1 node means the procedure is an unconditional no-op).

A C<Procedure> with a specified I<body>
specifies a simple statement tree of named statement
nodes, each of which is a tuple of one of its C<stmt.\w+_stmts> attributes.
It must have at least 1 member node, and
all member nodes must define a simple statement node tree, such
that every member except one (which is the root node) has one of its peers
as a parent node, and no direct cycles between members are permitted (only
indirect cycles based on procedure invocations are allowed); the
name of the root node must be the empty string.  The root node must also be
a compound statement node, meaning a tuple of the procedure's
C<stmt.compound_stmts> attribute; while making this requirement isn't
strictly necessary in general, that requirement allows the corresponding
concrete Muldis D grammars to be simpler, and a compound statement node
would end up being the root anyway in 99% of likely real procedures.  The
statement tree should reference all of the parameters and lexical variables
that the procedure has, but this isn't a strict requirement.

C<Procedure> has a distributed primary key over the C<name> attributes of
C<upd_params> and C<ro_params> and C<vars> and the C<name> attributes of
all the attributes of C<stmt>.  Its default value has zero parameters and
has no specified I<body>.

=head2 sys.std.Core.Type.Cat.SystemService

A C<SystemService> defines a C<system-service>, which is a kind of
procedure.  C<SystemService> is a proper subtype of C<Procedure> where for
every member value its C<is_system_service> attribute is C<Bool:True>.

=head2 sys.std.Core.Type.Cat.Transaction

A C<Transaction> defines a C<transaction>, which is a kind of procedure.
C<Transaction> is a proper subtype of C<Procedure> where for every member
value its C<is_transaction> attribute is C<Bool:True> and its
C<is_system_service> attribute is C<Bool:False>.

=head2 sys.std.Core.Type.Cat.StmtNodeSet

A C<StmtNodeSet> is a C<Database> that specifies a set of named
statement nodes.  It is typically composed into a procedure.  Each
tuple of a C<StmtNodeSet> attribute is a named statement node, from
which non-implicitly-atomic procedural Muldis D code is composed.

Note that, regarding Muldis D's feature of a statement node having an
explicit C<name> that can be referenced by "leave" and "iterate" control
flow statements to leave or re-iterate the corresponding block, both SQL
and Perl have native counterpart features in the form of block labels.

A C<StmtNodeSet> has these 11 attributes:

=over

=item C<ovl_sca_val_stmts> - C<OVLScaValStmtNodeSet>

These are statement nodes that represent the assignment to local variables
of newly selected scalar values of types such that all of the standard
Muldis D dialects provide special "opaque value literal" syntax specific to
the type.

=item C<leave_stmts> - C<LeaveStmtNodeSet>

These are statement nodes that represent abnormal block exit statements.

=item C<compound_stmts> - C<CompoundStmtNodeSet>

These are statement nodes that each represent a compound statement having a
sequence of 0..N procedure statements.

=item C<nil_func_invo_stmts> - C<NilFuncInvoStmtNodeSet>

These are statement nodes that represent niladic function invocations and
the assignment to local variables of the results of those invocations.

=item C<imp_invo_stmts> - C<ImpInvoStmtNodeSet>

These are statement nodes that represent imperative routine (updater,
recipe, or procedure) invocations.

=item C<try_catch_stmts> - C<TryCatchStmtNodeSet>

These are statement nodes that represent try-catch control flow statements.

=item C<if_else_stmts> - C<IfElseStmtNodeSet>

These are statement nodes that represent if-else control flow statements.

=item C<given_when_def_stmts> - C<GivenWhenDefStmtNodeSet>

These are statement nodes that represent given-when-default control flow
statements.

=item C<iterate_stmts> - C<IterateStmtNodeSet>

These are statement nodes that represent abnormal block restart statements.

=item C<loop_stmts> - C<LoopStmtNodeSet>

These are statement nodes that represent generic looping block statements.

=item C<ap_material_nc_sel_stmts> - C<APMaterialNCSelStmtNodeSet>

These are statement nodes that represent the assignment to local variables
of newly selected routine or type reference values.

=back

There is a distributed primary key over the C<name> attributes of all of a
C<StmtNodeSet>'s attributes.  Its default value is empty.

=head2 sys.std.Core.Type.Cat.OVLScaValStmtNodeSet

An C<OVLScaValStmtNodeSet> is a C<DHRelation> that specifies a set of
atomic statement nodes where each node represents the assignment to a
variable (or parameter) of a hard-coded scalar literal that is I<not> being
specified explicitly in terms of possrep attributes, but rather is
specified using special "opaque value literal" syntax that all of the
Muldis D standard dialects provide.  Using one of these statement nodes
should be an effective alternative to either declaring a niladic function
or declaring (or extending) an updater that simply combines a simple scalar
selecting expression node with an C<assign> updater call.

An C<OVLScaValStmtNodeSet> has these 4 attributes:

=over

=item C<name> - C<Name>

This is the declared name of the statement node.

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about the statement (leaf) node.

=item C<target> - C<Name>

This is name of the local parameter or variable that will have the newly
selected scalar value assigned to it.

=item C<value> - C<OVLScalar>

This is the actual scalar value that the statement node is selecting.

=back

An C<OVLScaValStmtNodeSet> has a unary primary key on the C<name>
attribute.  Its default value is empty.

=head2 sys.std.Core.Type.Cat.LeaveStmtNodeSet

A C<LeaveStmtNodeSet> is a C<DHRelation> that specifies a set of
statement leaf nodes where each node represents an instruction to
abnormally exit the block defined by a parent statement node (a normal exit
is to simply execute to the end of the block).  If the parent node in
question is the root statement node for the statement-containing procedure,
that is, if the parent node has the empty string as its name,
then the latter will be exited; this is how a "return" statement is
represented, but "return" is still easy to recognize because the root node
always has the empty string as its name.  If the parent node in question is
an iterating or looping statement, then any remaining iterations it might
have had are skipped, especially useful if it was an infinite loop.

A C<LeaveStmtNodeSet> has these 3 attributes:

=over

=item C<name> - C<Name>

This is the declared name of the statement node.

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about the statement leaf node.

=item C<leave> - C<Name>

This is the name of the parent statement node we wish to abnormally exit;
note that this reference does not count as making the other node a child of
the current one, so this reference does not contribute to a cycle.

=back

A C<LeaveStmtNodeSet> has a unary primary key on the C<name> attribute,
plus a unary (unique) key on the C<leave> attribute.  Its default value is
empty.

=head2 sys.std.Core.Type.Cat.CompoundStmtNodeSet

A C<CompoundStmtNodeSet> is a C<DHRelation> that specifies a set of
statement nodes where each node is a compound statement composed of a
sequence of 0..N other statements.

A C<CompoundStmtNodeSet> has these 3 attributes:

=over

=item C<name> - C<Name>

This is the declared name of the statement node.

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about either the statement node or
the statement node (sub-)tree it is the root of.

=item C<stmts> - C<array_of.Name>

This is a sequence of names of 0..N other local statement nodes; the
current compound statement consists of having those other statements
execute in this given sequence.

=back

A C<CompoundStmtNodeSet> has a unary primary key on the C<name>
attribute.  Its default value is empty.

=head2 sys.std.Core.Type.Cat.NilFuncInvoStmtNodeSet

A C<NilFuncInvoStmtNodeSet> is a C<DHRelation> that specifies a set of
atomic statement nodes where each node represents the assignment to a
variable (or parameter) of the result of an invocation of a niladic
function (with no arguments).  The invoked function can be either
user-defined or system-defined.  Using one of these statement nodes should
be an effective alternative to declaring (or extending) an updater that
simply combines a single niladic-function-invoking expression node with an
C<assign> updater call, such as when you want to set a variable to an
arbitrarily complex but statically defined value.

A C<NilFuncInvoStmtNodeSet> has these 4 attributes:

=over

=item C<name> - C<Name>

This is the declared name of the statement node.

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about the statement (leaf) node.

=item C<target> - C<Name>

This is name of the local parameter or variable that will have the result
value of the function invocation assigned to it.

=item C<function> - C<MaterialNC>

This is the name of the function being invoked by the statement node.

=back

A C<NilFuncInvoStmtNodeSet> has a unary primary key on the C<name>
attribute.  Its default value is empty.

=head2 sys.std.Core.Type.Cat.ImpInvoStmtNodeSet

An C<ImpInvoStmtNodeSet> is a C<DHRelation> that specifies a set of
statement nodes where each node is an invocation of an imperative routine
(updater, recipe, or procedure) with specific arguments.  The invoked
routine can be either user-defined or system-defined.  Iff the invoked
routine is an updater or a recipe, then that statement node is an atomic
statement node.

An C<ImpInvoStmtNodeSet> has these 5 attributes:

=over

=item C<name> - C<Name>

This is the declared name of the statement node.

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about either the statement node or
the statement node (sub-)tree it is the root of.

=item C<imperative> - C<MaterialNC>

This is the name of the imperative routine being invoked.

=item C<upd_args> - C<IISArgVarMap>

These are the 0..N subject-to-update arguments to the imperative routine
invocation, as-per C<ro_args>; but iff the routine being invoked is an
updater, then there must instead be 1..N subject-to-update arguments,
because an updater must take at least 1 subject-to-update argument.

=item C<ro_args> - C<IISArgVarMap>

These are the 0..N read-only arguments to the imperative routine
invocation.  Each element defines one argument value, with the element
C<arg> matching the invoked routine's parameter name, and the element
C<var> naming a local or global variable or statement-containing-procedure
parameter which defines the value.

=back

An C<ImpInvoStmtNodeSet> has a unary primary key on the C<name>
attribute.  Its default value is empty.  There is a distributed primary
key over the C<name> attributes of C<upd_args> and C<ro_args>.

=head2 sys.std.Core.Type.Cat.IISArgVarMap

An C<IISArgVarMap> is a C<DHRelation>.  It defines a set of argument names,
with a declared local or global variable (or parameter or pseudo-variable)
name for each.  It is used to define argument lists for routine invocations
by procedures.  An C<IISArgVarMap> has 2 attributes, C<arg> (a C<Name>) and
C<var> (a C<Name>); the C<arg> is the name of the routine argument,
and comprises a unary key; the C<var> is the invocation name of the
variable (or parameter or pseudo-variable) which defines the value for the
argument.  Its default value has zero tuples.

=head2 sys.std.Core.Type.Cat.TryCatchStmtNodeSet

A C<TryCatchStmtNodeSet> is a C<DHRelation> that specifies a set of
statement nodes where each node represents a try-catch control flow
statement.  A try-catch-stmt node is conceptually a wrapper over a pair
of C<ImpInvoStmtNodeSet> named I<try> and I<catch>, where I<try> is
unconditionally invoked first and then iff I<try> throws an exception then
it will be caught and I<catch> will be invoked immediately after to handle
it; if I<catch> also throws an exception then it will not be caught.  Each
of the invoked procedures can be either user-defined or system-defined.

A C<TryCatchStmtNodeSet> has these 4 attributes:

=over

=item C<name> - C<Name>

This is the declared name of the statement node.

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about either the statement node or
the statement node (sub-)tree it is the root of.

=item C<try> - C<Name>

This is the name of a local routine invocation statement node that will
be invoked first unconditionally; any thrown exception will be caught.

=item C<catch> - C<maybe_of.Name>

Iff C<catch> is a C<Just>, it is the name of a local routine invocation
statement node that will be invoked second iff the C<try> routine throws
an exception, and it will receive that exception for handling via its
single mandatory parameter C<topic> (which is C<Exception>-typed); iff
C<catch> is C<Nothing>, then there is no second routine invocation,
meaning any exception thrown by C<try> is ignored; any exception thrown by
C<catch> will not be caught.

=back

A C<TryCatchStmtNodeSet> has a unary primary key on the C<name>
attribute.  Its default value is empty.

=head2 sys.std.Core.Type.Cat.IfElseStmtNodeSet

An C<IfElseStmtNodeSet> is a C<DHRelation> that specifies a set of
statement nodes where each node represents an N-way if-else control flow
statement.  An C<IfElseStmtNodeSet> is essentially the imperative
version of the functional C<IfElseExprNodeSet>, except that for design
simplicity, all of the conditionals need to be pre-evaluated and their
boolean results stored in variables (but this could be a lazy though still
necessarily deterministic operation, so work isn't actually done if the
results aren't needed); if any conditionals could only be conditionally
evaluated, then the necessary logic means this if-else statement must be
broken up into multiple nested if-else.

An C<IfElseStmtNodeSet> has these 4 attributes:

=over

=item C<name> - C<Name>

This is the declared name of the statement node.

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about either the statement node or
the statement node (sub-)tree it is the root of.

=item C<if_then> - C<array_of.IfThenVarStmtMap>

This is a sequence of 0..N conditional result variable names, each of which
has an associated statement.  Each conditional result will be tested in
order while the previous conditional result is C<Bool:False>; once a
conditional result is C<Bool:True>, its associated statement will be
invoked; no statements will be invoked except the one with the true
conditional result.

=item C<else> - C<maybe_of.Name>

Iff none of the conditional results in C<if_then> is C<Bool:True> (or as a
trivial case, if C<if_then> is an empty sequence), then the statement
represented by the local statement node named by C<else> will be invoked
iff C<else> is a C<Just>; if under the first circumstance C<else> is
C<Nothing>, then the whole if-else will have been a no-op.

=back

An C<IfElseStmtNodeSet> has a unary primary key on the C<name>
attribute.  Its default value is empty.

=head2 sys.std.Core.Type.Cat.IfThenVarStmtMap

An C<IfThenVarStmtMap> is a C<DHTuple>.  It defines an element of an
if-else sequential statement.  An C<IfThenVarStmtMap> has 2 attributes,
C<if> (a C<Name>) and C<then> (a C<Name>); C<if> has the name of a
local or global variable (or parameter), and C<then> has the name of a
statement node.  The C<if> node is the conditional result variable name; if
that conditional result is C<Bool:True>, then the C<then> statement node is
invoked; otherwise, C<then> is not invoked.  Its default value has the
default value where each attribute is the default of its declared type.

=head2 sys.std.Core.Type.Cat.GivenWhenDefStmtNodeSet

A C<GivenWhenDefStmtNodeSet> is a C<DHRelation> that specifies a set of
statement nodes where each node represents an N-way given-when-default
switch control flow statement that dispatches based on matching a single
value with several options.  A C<GivenWhenDefStmtNodeSet> is essentially
the imperative version of the functional C<GivenWhenDefExprNodeSet>.

A C<GivenWhenDefStmtNodeSet> has these 5 attributes:

=over

=item C<name> - C<Name>

This is the declared name of the statement node.

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about either the statement node or
the statement node (sub-)tree it is the root of.

=item C<given> - C<Name>

This is name of the local parameter or variable that supplies the single
operand value that is common to all the conditions; it is the control value
for the statement.

=item C<when_then> - C<WhenThenVarStmtMap>

This is a set of distinct condition operand values, each of which has an
associated statement.  If a condition operand matches the value of
C<given>, its associated statement will be invoked; no statements will be
invoked except the one with the matching conditional operand.

=item C<default> - C<maybe_of.Name>

Iff none of the condition operand values in C<when_then> matches the value
of C<given> (or as a trivial case, if C<when_then> has no tuples), then the
statement represented by the local statement node named by C<default> will
be invoked iff C<default> is a C<Just>; if under the first circumstance
C<default> is C<Nothing>, then the whole given-when-default will have
been a no-op.

=back

A C<GivenWhenDefStmtNodeSet> has a unary primary key on the C<name>
attribute.  Its default value is empty.

=head2 sys.std.Core.Type.Cat.WhenThenVarStmtMap

A C<WhenThenVarStmtMap> is a C<DHRelation>.  It defines a set of dispatch
options for a given-when-default statement.  A C<WhenThenVarStmtMap> has 2
attributes, C<when> (a C<Name>) and C<then> (a C<Name>); C<when> has
the name of a local or global variable (or parameter), and C<then> has the
name of a statement node.  The C<when> node is the not-common / distinct
operand for each condition.  If a C<when> value is matched, then the
C<then> statement node is invoked; otherwise, C<then> is not invoked.  Its
default value has zero tuples.

=head2 sys.std.Core.Type.Cat.IterateStmtNodeSet

An C<IterateStmtNodeSet> is a C<DHRelation> that specifies a set of
statement leaf nodes where each node represents an instruction to
abnormally end the current iteration of a looping block defined by a parent
statement node, and then start at the beginning of the next iteration of
that loop if there are any left ("normal" is to simply execute to the end
of the block before starting the next iteration).  The same semantics apply
for the beginning of the next loop as if the current block iteration had
executed to the end before repeating.  In fact, a looping block isn't even
required; an iterate node can also be used to "redo" any parent statement.

An C<IterateStmtNodeSet> has these 3 attributes:

=over

=item C<name> - C<Name>

This is the declared name of the statement node.

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about the statement leaf node.

=item C<iterate> - C<Name>

This is the name of the parent statement node we wish to abnormally exit
and restart; note that this reference does not count as making the other
node a child of the current one, so this reference does not contribute to a
cycle.

=back

An C<IterateStmtNodeSet> has a unary primary key on the C<name>
attribute, plus a unary (unique) key on the C<iterate> attribute.  Its
default value is empty.

=head2 sys.std.Core.Type.Cat.LoopStmtNodeSet

A C<LoopStmtNodeSet> is a C<DHRelation> that specifies a set of statement
nodes where each node represents a generic looping statement block which
iterates until a child "leave" statement executes.

A C<LoopStmtNodeSet> has these 3 attributes:

=over

=item C<name> - C<Name>

This is the declared name of the statement node.

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about either the statement node or
the statement node (sub-)tree it is the root of.

=item C<loop> - C<Name>

This is the name of the local statement node that will get executed for
each iteration of the loop; typically it has a sub-tree of statement nodes.

=back

A C<LoopStmtNodeSet> has a unary primary key on the C<name> attribute.
Its default value is empty.

=head2 sys.std.Core.Type.Cat.APMaterialNCSelStmtNodeSet

An C<APMaterialNCSelStmtNodeSet> is a C<DHRelation> that specifies a set of
atomic statement nodes where each node represents the assignment to a
variable (or parameter) of a newly selected value of the
C<sys.std.Core.Type.Cat.AbsPathMaterialNC> type, which is selected in terms
of a value of the C<sys.std.Core.Type.Cat.RelPathMaterialNC> type.  Using
one of these statement nodes should be an effective alternative to either
declaring a niladic function or declaring (or extending) an updater that
simply combines an C<AbsPathMaterialNC> selecting expression node with an
C<assign> updater call.

An C<APMaterialNCSelStmtNodeSet> has these 4 attributes:

=over

=item C<name> - C<Name>

This is the declared name of the statement node.

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about the statement leaf node.

=item C<target> - C<Name>

This is name of the local parameter or variable that will have the newly
selected C<AbsPathMaterialNC> value assigned to it.

=item C<referencing> - C<RelPathMaterialNC>

This is the name, from the point of view of the procedure embedding this
statement node, of the routine or type that the new C<AbsPathMaterialNC>
value is supposed to facilitate portable invoking of.

=back

An C<APMaterialNCSelStmtNodeSet> has a unary (unique) key on the C<name>
attribute.  Its default value is empty.

=head1 TYPES FOR DEFINING DATA TYPES

=head2 sys.std.Core.Type.Cat.ScalarType

A C<ScalarType> is a C<DHTuple>.  It defines either a new
scalar root type with at least 1 possrep, or it defines a subtype
of some other scalar type which also adds at least one possrep to
the other type.  Either way, every possrep defines a candidate
representation that can handle every value of the [|sub]type it is defined
with, and the Muldis D implementation may choose for itself which of these,
or some other alternative, is the actual/physical representation.  Whether
a declared type is scalar or dh-scalar depends only on the declared
types of the attributes its possreps compose, whether any are
non-deeply-homogeneous
or none are.  You can not declare a scalar root type at all except
by using a C<ScalarType>, and you can not define a scalar type
with an incompletely defined attribute list at all.

A C<ScalarType> has these 7 attributes:

=over

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about the scalar
[|sub]type as a whole.

=item C<composed_mixins> - C<ComposedMixinSet>

These are the names of the 0..N mixin types, if any, that the new scalar
type composes, and therefore the new type is a subtype of all of them.

=item C<base_type> - C<maybe_of.RPTypeNC>

Iff the type being defined is a scalar root type, then
C<base_type> is not applicable and is C<Nothing>.  Iff the type being
defined is a subtype of some other scalar type, then C<base_type>
is a C<Just> whose sole element is the name of that other type.  Note
that any type named by C<base_type> must itself be a scalar root
type or a subtype of one.

=item C<subtype_constraint> - C<maybe_of.RPFunctionNC>

Iff the type being defined is a scalar root type, or it is a
non-proper subtype of some other type, then C<subtype_constraint> is not
applicable and is C<Nothing>.  Iff the type being defined is a proper
subtype of some other scalar type, then C<subtype_constraint> is a
C<Just> whose sole element matches the invocation name of a
C<type-constraint> function that determines what base type values are part
of the subtype.  The function that this names must have a
single C<topic> parameter whose declared type is that named by
C<base_type>, and whose argument is the value to test; the function's
result type must be C<Bool>.  This constraint function may only
reference possreps of the base type, and may not reference possreps of the
type being defined.  Note that, strictly speaking, C<subtype_constraint>
may actually be less restrictive than the total constraint of the subtype
as a whole, because the total constraint is defined by I<and>-ing the
constraints of the base types and the C<subtype_constraint> and the
constraints of all the possreps of the subtype; therefore, mainly the
C<subtype_constraint> needs to be just restricting enough so that the
inter-possrep mapping functions can handle the base type values that it
accepts, so it is possible to apply the new possreps' constraints.  Now if
C<subtype_constraint> were otherwise so simple as to unconditinally result
in C<Bool:True>, then simply making it C<Nothing> has the same effect.

=item C<possreps> - C<PossrepSet>

These are the 1..N possrep definitions that comprise this type such that
each one fully defines a set of attributes plus restrictions on their
collective values whereby it defines a representation of all values of this
type.  Note that if multiple scalar types are related to each
other such that more than one declares possreps for at least one common
value, then the C<name> attribute of the C<possreps> attributes of all of
those types' definitions have a distributed primary key over them.  Note
that, to keep things simple and deterministic under the possibility of
diamond subtype/supertype relationships (such that the generic
system-defined scalar possrep attribute accessors can work), Muldis D
requires all of the possreps of all scalar types having a common scalar
root type to have mutually distinct names, regardless of whether any
subtypes have values in common; this can be enforced at
type-definition-in-catalog time since all types that can interact are in
the same depot.

=item C<possrep_maps> - C<PossrepMapSet>

When this type has more than one possrep applicable to all of its values,
these are the definitions of mapping functions for deriving the
representation of a value in one possrep directly from the representation
in another possrep, and also directly in the reverse.  Every one of this
type's possreps must be mapped bidirectionally to every other one of its
possreps, either directly or indirectly.  So for C<P> total possreps, the
total number of bidirectional maps C<M> is in C<(P-1) ≤ M ≤ ((P-1)*P/2)>.
When a subtype is adding possreps to an other base type, all of the mapping
functions are defined with the subtype.

=item C<default> - C<maybe_of.RPFunctionNC>

Iff it is a C<Just>, then C<default>
matches the invocation name of a C<named-value> function that
results in the default scalar value of the [|sub]type; it has
zero parameters and its result type is the same as the scalar type
being defined.  Iff C<default> is C<Nothing> and
C<base_type> is C<Nothing>, then semantics are as if it were a defined name
that resulted in a value of the type being defined where all of the possrep
attr values were the default values of their declared types; but if the
type being defined has multiple possreps and going the by-attr-defaults
route with all of the possreps doesn't produce the same value of the type
being defined, then a C<default> of C<Nothing> is invalid and it must be a
C<Just>.  Iff C<default> is C<Nothing> and C<base_type> is a C<Just>,
then the subtype will use the same default value as its base type; but if
the subtype's value set excludes said value, then a C<default> of
C<Nothing> is invalid and C<default> must be a C<Just>.

=back

The default value of C<ScalarType> defines a scalar root type with
a single possrep whose name is the empty string and that has no attributes;
it is a singleton type, whose default value is its only value.

=head2 sys.std.Core.Type.Cat.PossrepSet

A C<PossrepSet> is a C<DHRelation> that specifies a set of possreps that
a scalar [|sub]type might consist primarily of.

A C<PossrepSet> has these 5 attributes:

=over

=item C<name> - C<Name>

This is the declared name of the possrep.

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about the possrep as a whole.

=item C<scm_vis_ord> - C<NNInt>

This is the visible order of this possrep's declaration relative to all of
the other possreps of this scalar type declaration.

=item C<tuple_type> - C<RPTypeNC>

This is the name of the tuple type from which the possrep being defined
composes its list of attributes (C<attrs>) and the basic constraints on
those as a collection (C<constraints>).  Said tuple type will most likely,
but isn't constrained to, not include any of the more complicated
specifications that typically are just used by tuples of relations or
tuples that are databases, such as virtual attribute maps or subset
constraints.  Note that, strictly speaking, any
constraint defined as part of (the tuple type defining) a possrep (where
there are multiple possreps) may actually be less restrictive than the
total constraint of the possreps' host
scalar [|sub]type as a whole, because the total constraint is
defined by I<and>-ing the constraints of all the possreps of the
[|sub]type (and, in the case of defining a subtype, with the
C<subtype_constraint> of the subtype and all base type constraints);
therefore, mainly any given possrep's constraints need to be just
restricting enough so that the inter-possrep mapping functions can handle
the arguments that it accepts, so it is possible to apply the other
possreps' constraints.

=item C<is_base> - C<Bool>

This is an optimization hint for Muldis D implementations that are not
intelligent enough to decide on a best physical representation for the
[|sub]type.  At most one of the type's possreps is singled out by having a
C<Bool:True> value here, so an implementation doesn't have to think and can
just use that as the basis for the physical representation.  To keep things
simple, only a possrep of a root type may be marked C<Bool:True>, so it can
apply consistently to all subtypes as well.  More intelligent
implementations are free to ignore C<is_base>, or just use it as a
tie-breaker if applicable.

=back

A C<PossrepSet> has a unary primary key on the C<name> attribute.  Its
default value is empty.  The default value of a tuple of C<PossrepSet>
has a C<name> that is the empty string and its C<tuple_type> is C<D0>; and
so the default is suitable for declaring a singleton scalar type.

=head2 sys.std.Core.Type.Cat.PossrepMapSet

A C<PossrepMapSet> is a C<DHRelation> such that each tuple in it
specifies a pair of mapping functions to bidirectionally derive a value of
a type between 2 of its possreps.

A C<PossrepMapSet> has these 5 attributes:

=over

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about this bidirectional mapping.

=item C<p1> - C<Name>

This is the declared name of one possrep.

=item C<p2> - C<Name>

This is the declared name of a second possrep.  The value of C<p2> must be
distinct from that of C<p1>, and moreover, the 2 values must be mutually
ordered so that the value of C<p1> is before the value of C<p2>; the latter
constraint defines a C<PossrepMapSet>'s canonical form.

=item C<p2_from_p1> - C<RPFunctionNC>

This matches the invocation name of a C<possrep-map> function that
derives the representation of the possrep named by C<p2> from that of the
possrep named by C<p1>.  The function that this names must have a single
C<topic> parameter whose declared type is the tuple type named by the
C<tuple_type> attribute of the possrep named by C<p1>; the function's
declared result type must be the tuple type named by the C<tuple_type>
attribute of the possrep named by C<p2>.  Note that every distinct
argument (domain) value of this function must have a distinct result
(range) value.

=item C<p1_from_p2> - C<RPFunctionNC>

This matches the invocation name of an inverse C<possrep-map> function
to that of C<p2_from_p1>.  I<Note that it would often be feasible for a
Muldis D implementation to automatically infer a reverse function, but for
now we still require it to be explicitly stated; the explicitly stated
inverse function could be generated though.  This design is subject to
change.>

=back

A C<PossrepMapSet> has a binary primary key on the C<p1> plus C<p2>
attributes.  Its default value is empty.

=head2 sys.std.Core.Type.Cat.TupleType

A C<TupleType> is a C<DHTuple>.  It defines either a new tuple heading
(set of attributes) with associated constraints for a tuple type having
that heading, or it defines a subtype of some other tuple type.  Note that
you also declare a database type using C<TupleType>, by declaring a tuple
type whose attributes are all relation or database typed.  Note that you
can not use a C<TupleType> to declare or subtype an incomplete type, as it
(or its supertype) must specify a complete set of attributes.  Note that a
C<TupleType> also typically doubles for defining a relation type (but it
doesn't have to), because a C<RelationType> requires one in terms of which
it is partly defined; each tuple of a value of the latter type is a value
of the former type.

A C<TupleType> has these 7 attributes:

=over

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about the tuple
[|sub]type as a whole.

=item C<composed_mixins> - C<ComposedMixinSet>

These are the names of the 0..N mixin types, if any, that the new tuple
type composes, and therefore the new type is a subtype of all of them.

=item C<base_type> - C<maybe_of.RPTypeNC>

Iff the type being defined is a tuple root type, then C<base_type> is
not applicable and is C<Nothing>.  Iff the type being defined is a
subtype of some other tuple type, then C<base_type> is a C<Just>
whose sole element is the name of that other type.

=item C<attrs> - C<NameTypeMap>

Iff the type being defined is a tuple root type, then C<attrs> defines
the 0..N attributes of the type.  Iff the type being defined is a subtype
of some other type, then the parent type's attribute list is used by
default, but C<attrs> of the current type may be used to apply additional
constraints by overriding the declared types of a subset of the parent's
attributes with types that are subtypes of the originals; an override is
done using matching C<name> attribute values of C<attrs>.  It is indeed
valid for a tuple type to have zero attributes (which is then just a
dh-tuple type by definition); in this case, a tuple type consists of
exactly one value, and any relation type defined over it consists of
exactly two values.

=item C<virtual_attr_maps> - C<VirtualAttrMapSet>

This defines the proper subset of this type's attributes that are virtual,
and how they are defined in terms of the rest of this type's attributes.
Note that the special functional dependencies between attributes defined
herein mean that some kinds of tuple constraints would be redundant.

=item C<constraints> - C<set_of.RelPathMaterialNC>

This, I<tuple constraints>,
matches the invocation names of 0..N tuple-constraint-defining materials
that (when I<and>-ed together) determine what combinations of tuple
attribute values denote values of the [|sub]type, besides the restrictions
imposed by the declared types of the attributes individually; they are
tuple type constraints that together validate a tuple as a whole.
Each tuple-constraint-defining material is one of these 4 material kinds:
C<value-constraint>, C<distrib-key-constraint>, C<subset-constraint>,
C<distrib-subset-constraint>.

A C<value-constraint> is a generalized type constraint function that must
have a single C<topic> parameter whose declared type is a tuple whose
attributes match those declared by C<attrs> and whose argument denotes the
value to test; the function's result type must be C<Bool>.  If the function
unconditionally results in C<Bool:True>, then all possible combinations of
attribute-allowable values are collectively allowed.  The function is
invoked either once to test a tuple value of the type being defined, or
multiple times to individually test every tuple in a relation value of a
type defined over the first type.

A C<distrib-key-constraint> is a
simple distributed (unique) key constraint that is
applicable to tuple/database values of the type being defined, that range
over specified relation-typed attributes of it.  At most one of a type's
C<distrib-key-constraint> may be privileged as the I<primary key>.
Note that a C<distrib-key-constraint>
is logically an abstraction syntax (the canonical simplest
form) for a particular kind of C<value-constraint> of the type being
defined, one that compares the cardinality of the union of the projection
of distributed key attributes of all key-participating relation-valued
attributes, with the sum of cardinalities of the source relation-valued
attributes; the attribute values comprise a distributed key if the
cardinalities are equal.

A C<subset-constraint> is a simple (non-distributed) subset constraint
(foreign key) that is applicable to tuple/database values of the type
being defined, that range over and relate tuples of specified
relation-typed attributes of it; they are a kind of referential constraint.
Each tuple of a child attribute must have a corresponding tuple in a
specific single parent attribute, where they correspond on the attributes
of the parent attribute that comprise a (unique) key of the latter.  Note
that a C<subset-constraint> is logically an abstraction syntax (the
canonical simplest form) for a particular kind of C<value-constraint> of
the type being defined, one that tests if the relational difference, where
a projection of the parent relation is subtracted from a corresponding
projection of the child relation (with attribute renaming if necessary), is
an empty relation; if the difference is an empty relation, then the subset
constraint is satisfied; otherwise, any difference tuples are from child
tuples that violate the subset constraint.

A C<distrib-subset-constraint> is a simple distributed subset constraint
(foreign key) that is applicable to tuple/database values of the type being
defined, that range over and relate tuples of specified relation-typed
attributes of it; they are a kind of referential constraint.  Each tuple of
a child attribute must have a corresponding tuple in one member of a
specific set of parent-alternative attributes (that have a distributed key
ranging over them), where they correspond on the attributes of the
parent-alternative attribute that comprise a distributed key on the latter.
Note that a C<distrib-subset-constraint> is logically an abstraction syntax
(the canonical simplest form) for a particular kind of C<value-constraint>
of the type being defined; it is as per C<subset-constraint> except that
the parent relation is the result of unioning appropriately renamed
projections of the member relations of the distributed key.

=item C<default> - C<maybe_of.RPFunctionNC>

Iff it is a C<Just>, then C<default>
matches the invocation name of a C<named-value> function that
results in the default tuple value of the [|sub]type; it has zero
parameters and its result type is the same as the tuple type
being defined.  Iff C<default> is C<Nothing> and
C<base_type> is C<Nothing>, then semantics are as if C<default> were
a defined name that resulted in a value of the type being defined where all
of the attr values were the default values of their declared types.  Iff
C<default> is C<Nothing> and C<base_type> is a C<Just>, then the
subtype will use the same default tuple value as its base type; but if the
subtype's value set excludes said value, then a C<default> of
C<Nothing> is invalid and C<default> must be a C<Just>.

=back

The default value of C<TupleType> defines a singleton tuple type that has
zero attributes and whose default value is its only value.

=head2 sys.std.Core.Type.Cat.RelationType

A C<RelationType> is a C<DHTuple>.  It defines either a new relation
heading (set of attributes) with associated constraints for a relation type
having that heading, or it defines a subtype of some other relation type.
Note that you can not use a C<RelationType> to declare or subtype an
incomplete type, as it (or its supertype) must specify a complete set of
attributes.  Note that in order to define a C<RelationType> there must
first exist a separate C<TupleType> in terms of which it is partly defined
(the reverse isn't true); each tuple of a value of the former type is a
value of the latter type.  Note that a single tuple type definition may be
shared by multiple relation type definitions, or it may be system-defined.

A C<RelationType> has these 6 attributes:

=over

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about the relation
[|sub]type as a whole.

=item C<composed_mixins> - C<ComposedMixinSet>

These are the names of the 0..N mixin types, if any, that the new relation
type composes, and therefore the new type is a subtype of all of them.

=item C<base_type> - C<maybe_of.RPTypeNC>

Iff the type being defined is a relation root type, then C<base_type> is
not applicable and is C<Nothing>.  Iff the type being defined is a
subtype of some other relation type, then C<base_type> is a C<Just>
whose sole element is the name of that other type.

=item C<tuple_type> - C<RPTypeNC>

This is the name of the tuple type from which the relation type being
defined composes its list of attributes and most of its other details.
Note that any other relation type referenced by C<base_type> must compose a
C<tuple_type> that has a common tuple supertype with the tuple type
referenced by the C<tuple_type> of the type being defined; that is, there
must be a diamond relationship (but both C<tuple_type> may reference
exactly the same tuple type).

=item C<constraints> - C<set_of.RelPathMaterialNC>

This, I<relation constraints>, matches the invocation names of 0..N
relation-constraint-defining materials that (when I<and>-ed together)
determine what sets of tuples of the type of C<tuple_type> comprise the
bodies of values of the relation [|sub]type; they are relation type
constraints that together validate a relation as a whole.  Each
relation-constraint-defining material is one of these 2 material kinds:
C<value-constraint>, C<key-constraint>.

A C<value-constraint> for a relation type is like
the C<value-constraint> of a
C<TupleType> but that each function's parameter is
relation-typed rather than tuple-typed; it is a generalized type
constraint that validates a relation as a whole.

A C<key-constraint> is an
explicit (unique) key constraint that is applicable to relation
values of the type being defined; it applies either as a candidate key or
as a unique key constraint, depending on context.  If there are no explicit
key constraints, then there is an implicit (unique) key over all attributes
of the relation type being defined, meaning that every possible tuple that
may individually be an element of a relation value of the type being
defined, may be in it at once.  If any explicit key constraints are
defined, then every one must be over a distinct proper subset of the type's
attributes, and moreover no key's attributes may be a subset of any other
key's attributes; if 2 such candidates appear, just use the one that has
the subset.  It is valid for a key to consist of zero attributes; in this
case, that key is the only key of the type, and values of the type may each
consist of no more than one tuple.  At most one one of a type's
C<key-constraint> may be privileged
as the I<primary key>.  Note that a C<key-constraint> is logically an
abstraction syntax (the canonical simplest form) for a particular kind of
C<value-constraint> of the type being defined, one that compares the
cardinality of a projection of a relation on its key attributes with the
cardinality of the original relation; the attribute values comprise a key
if the cardinalities are equal.

=item C<default> - C<maybe_of.RPFunctionNC>

Iff it is a C<Just>, then C<default>
matches the invocation name of a C<named-value> function that
results in the default relation value of the [|sub]type; it has
zero parameters and its result type is the same as the relation
type being defined.  Iff C<default> is
C<Nothing> and C<base_type> is C<Nothing>, then semantics are as if
C<default> were a defined name that resulted in a value of the
type being defined that had zero tuples.  Iff C<default> is
C<Nothing> and C<base_type> is a C<Just>, then the subtype will use the
same default relation value as its base type; but if the subtype's value
set excludes said value, then a C<default> of C<Nothing> is
invalid and C<default> must be a C<Just>.

=back

The default value of C<RelationType> defines a relation type that has
zero attributes and whose default value is the one with zero tuples.

=head2 sys.std.Core.Type.Cat.VirtualAttrMapSet

A C<VirtualAttrMapSet> is a C<DHRelation> that defines special functional
dependencies between attributes of a nonscalar data type, such
that, on a per-tuple basis, some attributes can be generated purely from
other attributes, and hence the former attributes may be virtual.  Each
tuple of a C<VirtualAttrMapSet> specifies 2 disjoint subsets of the
nonscalar's attributes, which are I<determinant> and I<dependent>
attributes respectively, where the values of the second set are generated
from the first using a C<virtual-attr-map> function.  Whether I<dependent>
attributes are computed when needed or pre-computed and stored (a trade-off
of storage space for speed) is implementation dependent, though users may
give hints to govern that performance decision.

The main reason for virtual attributes to exist is to provide a fundamental
feature of a relational database where multiple perceptions of the same
data can exist at once; each user can perceive the same data being
organized according to their own preferences, and even if the actual means
of storing the data changes over time, the users continue to be able to
perceive it in the same ways as before the change.

The most important use case of virtual attributes is when the data type
having them is a database type, all of whose attributes are relations (or
databases); and so these attributes define database relvars, with
non-virtual and virtual attributes being base and virtual relvars,
respectively (which correspond to the SQL concepts of base tables and
views, respectively).  The idea in general is that users can work with any
relvar without knowing whether it is base or virtual, and so if
implementations change later such that real relvars become virtual or
vice-versa, users could continue as if nothing changed.

A less common use case of virtual attributes is in (typically non-database)
nonscalar types when users want to treat non-identical values as being
distinct in some situations and non-distinct in others.  For example they
want to do case-insensitive matching of character data, or alternately they
want a case-insensitive (unique) key constraint on such, but either way
they want the case of the data preserved.  In this situation, a base
attribute can exist with the original case-preserved data, and a dependent
virtual attribute can exist with the first's values folded to uppercase
(eliminating any case differences); so then the key constraint can be
placed on the virtual attribute to get the desired semantics, and the
matching can be done against the same.

All permissable operations on virtual [|pseudo-]variables are such that the
semantics of updating them is the same as for updating base
[|pseudo-]variables, with respect to I<The Assignment Principle>: Following
assignment of a value C<v> to a variable C<V>, the comparison C<v = V>
evaluates to TRUE.  Just as an update to determinant variables will have
the cascade effect of updating their dependent variables such that the
functional dependency between them continues to hold, the reverse also must
happen.  Any update to dependent variables must have the side effect of
updating their determinant variables.  Specifically, the implementing code
of an update to dependents must be rewritten behind the scenes to become
instead an update to their determinants, as if the latter was what the
users had actually written, such that following the then-first update of
the determinants, the cascading update to the dependents by the functional
dependency must result in the same dependents' values that they would have
had if the dependents were just base variables being updated by the
original code.  If such a code rewrite can not be done, such as due to
information lost in the functional dependency, then the operation
attempting to update the dependent attributes must fail.  Sometimes the
code rewrite can be done automatically by the DBMS, and sometimes it can
succeed if the map definer gives explicit details on how to accomplish it.

Because Muldis D requires a strong degree of determinism in the whole
system, sometimes users have to provide explicit details on how to
accomplish a reverse mapping, even if it is possible to automatically
generate such, because there may be multiple ways to do a reverse map that
satisfy I<The Assignment Principle>, so the explicitness would be to pick
exactly one of those, so that how determinants are updated is predictable
in an implementation-portable manner.  For example, if a virtual relvar
C<V> is defined as the simple relational union of 2 other relvars C<R1> and
C<R2>, then a tuple insertion into C<V> could be rewritten at least 3
ways, which are an insertion into just C<R1>, or into just C<R2>, or into
both C<R1> and C<R2>; so for predictability's sake, the map should specify
which option to do (which can vary on a case-by-case basis).

I<This all being said, for the moment the C<VirtualAttrMapSet> type does
not give a way to manually specify a reverse function, so for now all the
virtuals are either read-only or updatable due to an automatically
generated reverse function, which might vary by implementation.  Fixing
this matter is TODO.  Note that the reverse functions might have to be
defined as per-tuple operations, separately for
insert/substitute/delete.>

A C<VirtualAttrMapSet> has these 6 attributes:

=over

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about this virtual attribute map.

=item C<scm_vis_ord> - C<NNInt>

This is the visible order of this declaration relative to all of
the other declarations beneath this tuple type declaration.

=item C<determinant_attrs> - C<NameNCMap>

These are the names of the determinant attributes.  Each name is given in 2
forms, called C<name> and C<nc>; C<nc> is the actual name of the
attribute as existing in the host type, and it may actually be a component
attribute of a host type attribute to any recursive depth (a single C<nc>
element means it is the actual host type element); C<name> is an alias by
which the attribute will be known in the C<virtual-attr-map> function; this
mapping exists so to make the determinant attributes look like direct
sibling attributes whereas in reality they can be further-away relatives,
just common components somewhere under the host type.

=item C<dependent_attrs> - C<NameNCMap>

These are the names of the dependent attributes; the structure of
C<dependent_attrs> is as per C<determinant_attrs>; none of these may be the
same as the names of the determinant attributes, since a virtual attribute
can't be defined in terms of itself.

=item C<virtual_attr_map> - C<RPFunctionNC>

This matches the invocation name of a C<virtual-attr-map> function
that derives a tuple of dependent attribute values from a tuple of
determinant attribute values.  The function that this names must
have a single C<topic> parameter whose declared type is a tuple whose
attributes match those of C<determinant_attrs>; the function's
result type must be a tuple whose attributes match those of
C<dependent_attrs>.  Note that the range of this function is typically
smaller than its domain, though it might not be.

=item C<is_updateable> - C<Bool>

This is C<Bool:True> if all of the dependent attributes should be treated
as updateable, because they have enough information to map any kinds of
updates (all of tuple insert/substitute/delete) back to their determinant
attributes, and the system should try to support updates against them.
This is C<Bool:False> if all of the dependent attributes should not be
considered updateable, either because it is known they don't have enough
information, or because we expect users will never try to update them, so
don't go to the trouble of supporting updates.

=back

A C<VirtualAttrMapSet> has a binary primary key on the C<determinant_attrs>
plus C<dependent_attrs> attributes; it also has a distributed primary key
over the C<dependent_attrs> attribute of all tuples.  Its default value is
empty.

=head2 sys.std.Core.Type.Cat.DomainType

A C<DomainType> is a C<DHTuple>.  It defines a new data type whose
values are all drawn from one or more specified other types (which can be
any not-C<Empty> types at all), and that generally speaking it is an
arbitrary subset of C<Universal> (and it has its own default value).  The
value set of the new data type is determined by taking a set of source
types' values and subtracting from it a set of filter types' values (and
then optionally applying 0..N type constraint functions to the values
remaining).  The likely most common such type definition scenario is
defining a simple explicit union type of 2+ scalar source types.  Less
likely for usage, you can also define simple explicit intersection or
difference or exclusion types.  A domain type does not define any changes
or supplements to the interfaces available for working with its values,
instead simply using those of its declared parent types.  A data type
defined in this way is typically not considered to exist when the system
wants to determine the MST (most specific type) of one of its values.  Note
that if you want to define a possrep-adding scalar subtype whose base is
a union/intersection/etc of other types (eg, to define a "Square" when you
have "Rectangle", "Rhombus"), you have to first define a C<DomainType>,
and then use that as the base type of a C<ScalarType>.

A C<DomainType> has these 8 attributes:

=over

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about the domain type as a whole.

=item C<composed_mixins> - C<ComposedMixinSet>

These are the names of the 0..N mixin types, if any, that the new domain
type composes, and therefore the new type is a subtype of all of them.

=item C<sources> - C<set_of.RPTypeNC>

These are the names of the 1..N other not-C<Empty> types that all the
values of the new data type are drawn from; the complete set of source
values is determined by either unioning (the default) or intersecting the
values of these types.

=item C<is_source_intersection> - C<Bool>

Iff this is C<Bool:True> then the set of source data types will be
intersected to determine the complete set of source values; iff this is
C<Bool:False> then the set of source data types will be unioned to
determine the complete set of source values.

=item C<filters> - C<set_of.RPTypeNC>

These are the names of the 0..N other types (which are generally subtypes
of those of C<sources>) that determine values which the new data type will
I<not> contain; the complete set of filter values is determined by either
unioning (the default) or intersecting the values of these types.

=item C<is_filter_intersection> - C<Bool>

Iff this is C<Bool:True> then the set of filter data types will be
intersected to determine the complete set of filter values, and if
C<filters> has no elements then the filter set is just C<Universal>; iff
this is C<Bool:False> then the set of filter data types will be unioned to
determine the complete set of filter values, and if C<filters> has no
elements then the filter set is just C<Empty>.

=item C<constraints> - C<set_of.RPFunctionNC>

This matches the invocation names of 0..N C<type-constraint> functions
that (when I<and>-ed together) determine what filter-type-passing
source-type values are part of the domain type.  The function
that each of these names must have a single C<topic> parameter whose
declared type is C<Universal>, unless there is exactly 1 C<sources> element
whereupon the declared type is the same as the source type, and whose
argument is the value to test; the function's result type must be
C<Bool>.  If the functions unconditionally result in C<Bool:True>, then all
filter-type-passing values are allowed.

=item C<default> - C<RPFunctionNC>

This matches the invocation name of a C<named-value> function that results
in the default value of the domain type; it has zero parameters and its
result type is the same as the domain type being defined.

=back

The default value of C<DomainType> defines an alias for C<Universal>,
with the same default value; it has just the source type C<Universal> and
zero filter types, both type lists are unioned, and C<constraints> is empty
(unconditionally C<Bool:True>).  Note that there is no valid combination of
C<DomainType> attribute values that would result in an alias for the
C<Empty> type, due to a default value for the type being mandatory.

=head2 sys.std.Core.Type.Cat.SubsetType

A C<SubsetType> is a C<DHTuple>.  It provides a relatively terse
method to define a simple subset-defined subtype of a single other
type (which can be any not-C<Empty> type at all), which is a common kind of
type to have.  The new type is either a proper or non-proper subset of the
other type, whose values are determined from applying 0..N type constraint
functions to the parent type; either way, the new type does declare its own
default value.  An alternate common scenario is to define a non-proper
subtype of its parent type that serves just to supply a different default
value for the context in which the new type is used.  A subset type
does not define any changes or supplements to the interfaces available for
working with its values, instead simply using those of its declared parent
type.  A data type defined in this way is typically not considered to exist
when the system wants to determine the MST (most specific type) of one of
its values.  You can only declare a nonscalar type with an incompletely
defined attribute list using a C<SubsetType> (or a C<DomainType>).

A C<SubsetType> has these 5 attributes:

=over

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about the subset type as a whole.

=item C<composed_mixins> - C<ComposedMixinSet>

These are the names of the 0..N mixin types, if any, that the new subset
type composes, and therefore the new type is a subtype of all of them.

=item C<base_type> - C<RPTypeNC>

This is the name of the not-C<Empty> other type that all the values of the
new data type are drawn from; the new type is being declared as a subtype
of that named by C<base_type>.

=item C<constraints> - C<set_of.RPFunctionNC>

This matches the invocation names of 0..N C<type-constraint> functions
that (when I<and>-ed together) determine what base type values are part of
the subset type.  The function that each of these names
must have a single C<topic> parameter whose declared type is that named
by C<base_type>, and whose argument is the value to test; the function's
result type must be C<Bool>.  If the functions unconditionally result in
C<Bool:True>, then the new type is a non-proper subtype of the base type.

=item C<default> - C<maybe_of.RPFunctionNC>

Iff it is a C<Just>, then C<default>
matches the invocation name of a C<named-value> function that
results in the default value of the subset type; it has zero
parameters and its result type is the same as the subset type
being defined.  Iff C<default> is C<Nothing>, then the
subset type will use the same default value as its base type; but if
the subset type's value set excludes said value, then a C<default> of
C<Nothing> is invalid and C<default> must be a C<Just>.

=back

The default value of C<SubsetType> defines an alias for C<Universal>,
with the same default value; it has the base type C<Universal> and
C<constraints> is empty (unconditionally C<Bool:True>).  Note that there is
no valid combination of C<SubsetType> attribute values that would
result in an alias for the C<Empty> type, due to a default value for the
type being mandatory.

=head2 sys.std.Core.Type.Cat.MixinType

A C<MixinType> is a C<DHTuple>.  It defines a new data type whose values
are a union of those from the zero or more other not-C<Empty> types that
specify themselves to be part of that union.  For all practical purposes, a
C<MixinType> declares a I<mixin> or I<interface> or I<role> (the last as
Perl 6 uses the term) which is meant to be composed into other types, such
that said other types are then at least labelled as being useable in
particular common ways, and optionally the mixin type may define attributes
or code that can be reused by the types that compose it.  For example,
C<Numeric> is a mixin type, and any types composing it such as C<Int> or
C<Rat> are thereby declaring themselves to support common numeric operators
such as addition and multiplication.  A union type declared by a
C<MixinType> is unlike one declared by a C<DomainType> in that the former
is I<open> and the latter is I<closed>; any user-defined type can add
itself to the domain of even a system-defined mixin-type (such as
C<Numeric>), whereas no type can add itself to the domain of a
system-defined domain-type (such as C<Bool>).  A data type defined by a
C<MixinType> is typically not considered to exist when the system wants to
determine the MST (most specific type) of one of its values.

A C<MixinType> has these 2 attributes:

=over

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about the mixin type as a whole.

=item C<composed_mixins> - C<ComposedMixinSet>

These are the names of the 0..N other mixin types, if any, that the new
mixin type composes.  Any other type that explicitly composes the new mixin
type will also implicitly compose all of the other mixin types that the new
mixin type composes, recursively; note that a mixin type is forbidden from
composing itself, directly or indirectly.

=back

The default value of C<MixinType> defines a mixin type has no comment and
composes no other mixins and that in isolation has no default value.

=head2 sys.std.Core.Type.Cat.ComposedMixinSet

A C<ComposedMixinSet> is a C<DHRelation>.  It defines a set of names of
declared mixin data types which are being composed by another type, and for
each it indicates whether the composing type is asserting that it will
provide the default value of the mixin type.  A C<ComposedMixinSet> has 4
attributes, C<type> (a C<RPTypeNC>), C<provides_its_default> (a C<Bool>),
C<scm_comment> (a C<Comment>), and C<scm_vis_ord> (a C<NNInt>); the C<type>
is the declared name of the mixin type being composed, and comprises a
unary key.  Its default value has zero tuples.

A providing composing type always gives its own default value for the
mixin's default; they can't be different; if you want different, declare a
subtype of the value provider to be what composes the mixin.  No more than
one visible type may declare provision of the default value for a mixin.
If a system-defined type claims to provide a default for a mixin, no
user-defined type ever can (see C<Ordered>, C<Ordinal>, C<Numeric>,
C<Stringy>).  If a system-defined mixin exists that no system-defined type
composes (see C<Instant>, C<Duration>) then exactly one user-defined type
in a mounted depot may claim to provide its default, and that only affects
code in that depot which asks for the default value of said types.  A
user-defined mixin type can only be composed by user-defined types in the
same depot.  Asking a mixin type for its default will fail unless a visible
type claims its default.  Iff exactly one visible type composes a mixin,
that one will provide the mixin's default value implicitly if it doesn't
explicitly claim to.

=head2 sys.std.Core.Type.Cat.KeyConstr

A C<KeyConstr> is a C<DHTuple>.  It specifies a candidate key or
unique key constraint for a relation type.

A C<KeyConstr> has these 3 attributes:

=over

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about the key as a whole.

=item C<attrs> - C<set_of.Name>

This defines the 0..N host relation attributes comprising the key.  If
this set is empty, then we have a nullary key which restricts the host
relation to have a maximum of 1 tuple.

=item C<is_primary> - C<Bool>

This is C<Bool:True> if this key has been designated the I<primary key> of
the relation (a relation may have at most one, or none, of those); it
is C<Bool:False> otherwise.  A primary key is privileged over candidate
keys in general, in that all of the attributes comprising the primary key
are likely to be treated as immutable in practice for the relation's
tuples, and hence are the best candidates for identifying tuples within
a relation over an extended term (if multiple keys conceptually have all
those qualities, then you could choose either as the primary, or perhaps
such a situation may indicate a flaw in your database design).  The common
concept of a tuple having an identity that is distinct from the sum total
of all its attribute values, such that one can say that a tuple is being
"updated" (rather than its host relation being the only thing that is
updated to hold a different set of tuples) is dependent in Muldis D on
the host relation having a primary key; if a tuple in a relation is
replaced by a distinct tuple whose values in the primary key attributes
are identical, it is only in this situation that we can consider that we
still have the same tuple, which was just updated, and that we have not
lost the old tuple and gained a new one.  The relation attributes
comprising a primary key are the best mapping values for automatic new
subset constraints and join conditions if the host relation type has to be
auto-split into several associated ones, for example because the physical
representation of this relation doesn't support RVAs; in fact, some
implementations may require that any relation having an RVA must also
have an explicit primary key, so it is easier for them to choose the key to
automatically relate a split relation on.

=back

The default value of C<KeyConstr> defines a nullary key.

=head2 sys.std.Core.Type.Cat.DistribKeyConstr

A C<DistribKeyConstr> is a C<DHTuple>.  It specifies a candidate
distributed (unique) key constraint over relation-valued attributes of a
tuple/database.

A C<DistribKeyConstr> has these 4 attributes:

=over

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about the distributed (unique) key
as a whole.

=item C<attrs> - C<set_of.Name>

This declares the 0..N attributes comprising the distributed (unique) key.
If this set is empty, then we have a nullary key which restricts all of the
relations participating in the distributed key to have a maximum of 1
tuple between them.  Note that the distributed key attribute names don't
have to match the names of any participating relation attributes.

=item C<relations> - C<DKMemRelAttrMap>

This names the 0..N relation-valued attributes of the host
tuple/database type that are participating in the distributed key, and
says which of each of their attributes maps to the attributes of the
distributed key itself.  If this set is empty, then the distributed key has
no effect.  The unary projection of every tuple of the C<key_attr>
attribute of C<relations> must be identical to C<attrs>.

=item C<is_primary> - C<Bool>

This has the same meaning as C<is_primary> of C<KeyConstr> but for being
distributed as if the relations distributed over were one relation.

=back

The default value of C<DistribKeyConstr> has all-empty attributes.

=head2 sys.std.Core.Type.Cat.SubsetConstr

A C<SubsetConstr> is a C<DHTuple>.  It specifies a (non-distributed) subset
constraint (foreign key constraint) over relation-valued
attributes of a tuple/database; a subset constraint
is a kind of referential constraint, that relates tuples of such
attributes.  Each tuple of a child attribute must have a corresponding
tuple in a specific single parent attribute, where they correspond on the
attributes of the parent attribute that comprise a (unique) key of the
latter.  Note that it is valid to define a subset constraint involving zero
attributes, in which case the constraint is that the parent relation must
have exactly one tuple when the child relation has at least one tuple.

A C<SubsetConstr> has these 5 attributes:

=over

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about the subset constraint as a
whole.

=item C<parent> - C<NameChain>

This is the name of the relation-valued attribute that is the parent in the
(non-distributed) subset constraint relationship.  But the attribute named
by C<parent> is only a direct attribute of the host type if C<parent> has 1
chain element; if it has more, then the host type attribute is a
tuple/database and any further elements serve to make C<parent> actually
address a component of said.

=item C<parent_key> - C<RelPathMaterialNC>

This matches the invocation name of the candidate key or unique key
constraint of C<parent>, explicitly declared as a C<key-constraint>
material, which defines the attributes of C<parent> that are
being matched on in the subset constraint.

=item C<child> - C<NameChain>

This is the name of the relation-valued attribute that is the child in the
(non-distributed) subset constraint relationship; its structure is as per
C<parent>.  Note that C<child> and C<parent> are allowed to be one and the
same.

=item C<attr_map> - C<SCChildAttrParentAttrMap>

This maps 0..N attributes of the child relation with the same number of
attributes of the parent relation; the mapped attribute names may or may
not be the same.

=back

The default value of C<SubsetConstr> has all-empty attributes.

=head2 sys.std.Core.Type.Cat.DistribSubsetConstr

A C<DistribSubsetConstr> is a C<DHTuple>.  It specifies a distributed
subset constraint (foreign key constraint) over relation-valued
attributes of a tuple/database; a distributed subset constraint
is a kind of referential constraint, that relates tuples of such
attributes.  Each tuple of a child attribute must have a corresponding
tuple in one member of a specific set of parent-alternative attributes
(that have a distributed key ranging over them), where they correspond on
the attributes of the parent-alternative attribute that comprise a
distributed key on the latter.  Note that it is valid to define a subset
constraint involving zero attributes, in which case the constraint is that
exactly one of the parent relations must have exactly one tuple when the
child relation has at least one tuple.

A C<DistribSubsetConstr> has these 4 attributes:

=over

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about the subset constraint as a
whole.

=item C<parent_distrib_key> - C<RelPathMaterialNC>

This matches the invocation name of the distributed (unique) key,
explicitly declared as a C<distrib-key-constraint> material, that
is the parent in the distributed subset constraint relationship; it defines
by proxy the attributes that are being matched on in the subset constraint.
But the distributed key named by C<parent_distrib_key> may not be directly
declared by the host type of this subset constraint; it might be declared
by the type of an attribute of the host type, if said attribute is a
tuple/database; so the only or last C<parent_distrib_key> chain element is
a key name, and any preceeding names are attribute names.

=item C<child> - C<NameChain>

This is the name of the relation-valued attribute that is the child in the
distributed subset constraint relationship.  But the attribute named by
C<child> is only a direct attribute of the host type if C<child> has 1
chain element; if it has more, then the host type attribute is a
tuple/database and any further elements serve to make C<child> actually
address a component of said.

=item C<attr_map> - C<SCChildAttrParentAttrMap>

This maps 0..N attributes of the child relation with the same number of
attributes of the parent distributed key; the mapped attribute names may or
may not be the same.

=back

The default value of C<DistribSubsetConstr> has all-empty attributes.

=head2 sys.std.Core.Type.Cat.DKMemRelAttrMap

A C<DKMemRelAttrMap> is a C<DHRelation> that names the 0..N relation-valued
attributes of a host tuple/database type that are participating in a
distributed key, and says which of each of their attributes maps to the
attributes of the distributed key itself.

A C<DKMemRelAttrMap> has these 3 attributes:

=over

=item C<rel_name> - C<NameChain>

This is the name of the relation-valued attribute that is participating
in the distributed key.  But the attribute named by C<rel_name> is only a
direct attribute of the host type if C<rel_name> has 1 chain element; if it
has more, then the host type attribute is a tuple/database and any
further elements serve to make C<rel_name> actually address a component of
said.

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about the participation.

=item C<attr_map> - C<DKRelAttrKeyAttrMap>

This maps 0..N attributes of the relation with the same number of
attributes of the distributed key.  Every tuple of C<attr_map> must have an
identical value for the unary projection on its C<key_attr> attribute; in
other words, they must all map with the same distributed key attributes.

=back

A C<DKMemRelAttrMap> has a unary primary key on the C<rel_name> attribute.
Its default value is empty.

=head2 sys.std.Core.Type.Cat.DKRelAttrKeyAttrMap

A C<DKRelAttrKeyAttrMap> is a C<DHRelation>.  It maps 0..N attributes of a
relation-valued attribute of a host tuple/database type participating
in a distributed key, to the same number of attributes of the distributed
key itself.  A C<DKRelAttrKeyAttrMap> has 2 attributes, C<rel_attr> and
C<key_attr>, each of those being a C<Name>, and each of those being a unary
key.  Its default value has zero tuples.

=head2 sys.std.Core.Type.Cat.SCChildAttrParentAttrMap

A C<SCChildAttrParentAttrMap> is a C<DHRelation>.  It maps 0..N attributes
of a child relation-valued attribute of a host tuple/database type
participating in a non-distributed or distributed subset constraint
(foreign key), to the same number of attributes of a parent such attribute
or a distributed key of the host.  A C<SCChildAttrParentAttrMap> has 2
attributes, C<child_attr> and C<parent_attr>, each of those being a
C<Name>, and each of those being a unary key.  Its default value has zero
tuples.

=head1 TYPES FOR DEFINING STIMULUS-RESPONSE RULES

=head2 sys.std.Core.Type.Cat.StimRespRule

A C<StimRespRule> is a C<DHTuple>.  It defines a new stimulus-response rule
which invokes a recipe or procedure automatically in response to some
stimulus; for now just the act of a depot being mounted is supported.

A C<StimRespRule> has these 3 attributes:

=over

=item C<scm_comment> - C<Comment>

This is an optional programmer comment about the rule as a whole.

=item C<stimulus> - C<Name>

This is always the value C<after-mount> for now.

=item C<response> - C<MaterialNC>

This is the name of the recipe or procedure being invoked.

=back

The default value of C<StimRespRule> defines a stimulus-response rule whose
stimulus is C<after-mount> and whose response is an invocation of the
procedure C<sys.std.Core.Cat.fail>.

=head1 SIMPLE GENERIC NONSCALAR TYPES

=head2 sys.std.Core.Type.Cat.D0

A C<D0> is a C<Database>.  It has exactly zero attributes; it is a
singleton type whose only value is also known as C<Tuple:D0>.  This exists
as a data type as a convenience for the definition of scalar singleton
types, which would typically use this as the tuple type which their possrep
is defined partially in terms of.

=head2 sys.std.Core.Type.Cat.NameTypeMap

A C<NameTypeMap> is a C<DHRelation>.  It defines a basic component list,
meaning a set of names, with a declared data type name for each.  It forms
the foundation for most componentized type definitions, including all
tuple and relation types (for which it is named I<heading>), and it is
used also for the components list of a scalar possrep.  It is also used
to define parameter lists for routines.  A C<NameTypeMap> has 4 attributes,
C<name> (a C<Name>), C<type> (a C<RPTypeNC>), C<scm_comment> (a
C<Comment>), and C<scm_vis_ord> (a C<NNInt>); the C<name> is the
declared name of the attribute or parameter, and comprises a unary key; the
C<type> is the declared data type of the attribute or parameter.  Its
default value has zero tuples.

=head2 sys.std.Core.Type.Cat.NameExprMap

A C<NameExprMap> is a C<DHRelation>.  It defines a basic component-values
list, meaning a set of names, with a declared local expression node (or
parameter) name for each.  It is used to define collection literals; one
C<NameExprMap> defines a whole C<Tuple> value.  It is also used to define
argument lists for routine invocations by functions or updaters or recipes.
A C<NameExprMap> has 3 attributes, C<name> and C<expr>, each of those being
a C<Name>, and C<scm_vis_ord> (a C<NNInt>); the C<name> is the name of the
tuple/etc attribute or routine argument, and comprises a unary key; the
C<expr> is the declared lexical name of the expression node (or parameter
or variable) which defines the value for the attribute or argument.  Its
default value has zero tuples.

=head2 sys.std.Core.Type.Cat.NameNCMap

A C<NameNCMap> is a C<DHRelation>.  It defines an association of a short
name with a name chain, to be used for aliasing the latter with the former
in a particular context.  A C<NameNCMap> has 3 attributes, C<name> (a
C<Name>), C<nc> (a C<NameChain>), and C<scm_vis_ord> (a C<NNInt>); each of
those is a unary key.  Its default value has zero tuples.

=head2 sys.std.Core.Type.Cat.AttrRenameMap

An C<AttrRenameMap> is a C<DHRelation>.  It is used as a specification for
how to rename attributes of some collection.  An C<AttrRenameMap> has 3
attributes, C<after> and C<before>, each of those being a C<Name>, and each
of those being a unary key; the 3rd attribute is C<scm_vis_ord> (a
C<NNInt>).  Its default value has zero tuples.

=head2 sys.std.Core.Type.Cat.OrderByName

An C<OrderByName> is a C<DHTuple>.  It defines an element of an order-by
sequential expression, which is a specification for how to order tuples of
a relation in terms of a list of their attributes to order on.  An
C<OrderByName> has 2 attributes, C<name> (a C<Name>) and
C<is_reverse_order> (a C<Bool>).  Its default value has the default value
of the C<Name> and C<Bool> types for their respective attributes.  I<Maybe
TODO:  Make C<name> a C<PNSQNameChain> instead to drill into TVAs or SVAs.>

=head1 TYPES FOR POSSIBLY CURRIED HIGHER-ORDER FUNCTIONS

=head2 sys.std.Core.Type.Cat.CurriedFuncNC

A C<CurriedFuncNC> is a (not necessarily deeply homogeneous) C<Tuple>.  It
is conceptually a I<curried higher-order function>, that is, an
C<APFunctionNC> referencing a function plus a set of zero or more arguments
to pre-bind to a same-degree subset of that function's read-only
parameters, such that the effective higher-order-function which this
references has appropriately fewer parameters remaining to bind to when it
is actually invoked.  A C<CurriedFuncNC> has 2 attributes, C<function> (an
C<APFunctionNC>) and C<args> (a C<Tuple>); C<function> names the actual
function to invoke, and C<args> names any arguments to pre-bind to its
parameters.  Whether or not its C<args> has any attributes that are not
deeply homogeneous is the sole determinant of whether a C<CurriedFuncNC> is
a C<DHTuple> rather than just a C<Tuple>.  Its default value is a reference
to the C<sys.std.Core.Universal.is_identical> function with no pre-bound
parameters.

=head2 sys.std.Core.Type.Cat.ValMapCFuncNC

C<ValMapCFuncNC> is a non-proper subtype of C<CurriedFuncNC> that is
conceptually a reference to a C<value-map> function.  Its default value is
a reference to the C<sys.std.Core.Cat.map_to_topic> function.

=head2 sys.std.Core.Type.Cat.ValFiltCFuncNC

C<ValFiltCFuncNC> is a non-proper subtype of C<ValMapCFuncNC> that is
conceptually a reference to a C<value-filter> function.  Its default value
is a reference to the C<sys.std.Core.Cat.pass_topic> function.

=head2 sys.std.Core.Type.Cat.ValRedCFuncNC

C<ValRedCFuncNC> is a non-proper subtype of C<CurriedFuncNC> that is
conceptually a reference to a C<value-reduction> function.  Its default
value is a reference to the C<sys.std.Core.Cat.reduce_to_v1> function.

=head2 sys.std.Core.Type.Cat.OrdDetCFuncNC

C<OrdDetCFuncNC> is a non-proper subtype of C<CurriedFuncNC> that is
conceptually a reference to an C<order-determination> function.  Its
default value is a reference to the C<sys.std.Core.Ordered.order> function.
This type is conceptually intended for use as the declared type of a
routine parameter that would take the name of an C<order-determination>
function, but that parameter is optional and should default to the
system-defined scalar ordering function when no argument is given to it.

=head1 TYPES FOR DEFINING EXCEPTIONS

=head2 sys.std.Core.Type.Cat.Exception

C<Exception> is a singleton scalar type whose only value represents a
generic thrown exception.  This type doesn't provide any means for a
I<catch> routine to introspect details about the exception, such as what
kind of exception it was, but rather simply says that something happened
which resulted in a Muldis D routine abnormally exiting.  Therefore, the
C<Exception> type is subject to be rewritten so it can carry the various
metadata that exceptions of typical programming languages can.  But in the
meantime, this singleton type affords Muldis D with completely functional
basic exception handling in that exceptions can be thrown and can be
caught, so that good program design involving the use of exceptions to draw
immediate attention to problems can be supported now.

=head1 SEE ALSO

Go to L<Muldis::D> for the majority of distribution-internal
references, and L<Muldis::D::SeeAlso> for the majority of
distribution-external references.

=head1 AUTHOR

Darren Duncan (C<darren@DarrenDuncan.net>)

=head1 LICENSE AND COPYRIGHT

This file is part of the formal specification of the Muldis D language.

Muldis D is Copyright © 2002-2010, Muldis Data Systems, Inc.

See the LICENSE AND COPYRIGHT of L<Muldis::D> for details.

=head1 TRADEMARK POLICY

The TRADEMARK POLICY in L<Muldis::D> applies to this file too.

=head1 ACKNOWLEDGEMENTS

The ACKNOWLEDGEMENTS in L<Muldis::D> apply to this file too.

=cut
