|
Language::MuldisD::Core - Muldis D core data types and operators |
Language::MuldisD::Core - Muldis D core data types and operators
This document is Language::MuldisD::Core version 0.9.2.
This document is part of the Muldis D language specification, whose root document is the Language::MuldisD manpage; you should read that root document before you read this one, which provides subservient details.
Muldis D has a mandatory core set of system-defined (eternally available) entities, which is referred to as the Muldis D core or the core; they are the minimal entities that all Muldis D implementations need to provide; they are mutually self-describing and are used to bootstrap the language; any entities outside the core, called Muldis D extensions, are non-mandatory and are defined in terms of the core or each other, but the reverse isn't true.
This current Core document features the boolean, order, integer,
rational, bit string, and character string types and operators, plus the
tuple and relation type constructors (and quasi- variants) and operators,
plus the type system minimal and maximal types, plus the special types used
to define the system catalog, and the polymorphic operators that all types,
or some types including core types, have defined over them.
Extensions are in these other documents: the Language::MuldisD::Ext::Temporal manpage, the Language::MuldisD::Ext::Spatial manpage.
Following are all the data types and data type factories described in this document, arranged in a type graph according to their proper sub|supertype relationships:
sys.Core.Universal.Universal
sys.Core.Universal.Empty
sys.Core.Scalar.Scalar
sys.Core.Ordered.Ordered
# The following are all regular ordered scalar types.
sys.Core.Bool.Bool
sys.Core.Order.Order
sys.Core.Int.Int
sys.Core.Int.UInt
sys.Core.Int.PInt
sys.Core.Rat.Rat
sys.Core.Rat.URat
sys.Core.Rat.PRat
sys.Core.Rat.BRat
sys.Core.Rat.DRat
sys.Core.Blob.Blob
sys.Core.Blob.NEBlob
sys.Core.Text.Text
sys.Core.Text.NEText
# The following are all nonscalar type factories.
sys.Core.Tuple.Tuple
sys.Core.Tuple.Database
sys.Core.Relation.Relation
sys.Core.Relation.Set
sys.Core.Relation.Maybe
sys.Core.Relation.Seq
sys.Core.Relation.Bag
# The following are all quasi-nonscalar type factories.
sys.Core.QuasiTuple.QuasiTuple
sys.Core.QuasiRelation.QuasiRelation
sys.Core.QuasiRelation.QuasiSet
sys.Core.QuasiRelation.QuasiMaybe
sys.Core.QuasiRelation.QuasiSeq
sys.Core.QuasiRelation.QuasiBag
Note that sys.Core.Universal.Empty is a proper subtype of all of the
other types in this graph, but every other type has only one immediate
supertype shown, and hence the graph of them is a simple hierarchy.
These system-defined subtypes are specific to defining the system catalog, more or less:
sys.Core.Universal.Universal
sys.Core.Universal.Empty
sys.Core.Scalar.Scalar
# The following is actually a union over many scalar types.
sys.Core.Cat.ScalarLiteral
sys.Core.Ordered.Ordered
# The following are all regular ordered scalar types.
sys.Core.Cat.Name
sys.Core.Cat.NameChain
sys.Core.Cat.FlattenedNameChain
# The following are all regular non-ordered scalar types.
sys.Core.Cat.E_TK
sys.Core.Cat.E_TDM
sys.Core.Cat.E_EK
sys.Core.Tuple.Tuple
# The following are all regular tuple types.
sys.Core.Cat.Type
sys.Core.Cat.Expr
sys.Core.Cat.Exception
sys.Core.Relation.Relation
# The following are all regular relation types.
sys.Core.Cat.NameTypeMap
sys.Core.Cat.NameMap
sys.Core.Cat.BiDiNameMap
sys.Core.Relation.Set
# The following are all regular set types.
sys.Core.Cat.SetOfName
sys.Core.Cat.SetOfSetOfName
sys.Core.Cat.SetOfNameMap
sys.Core.Cat.SetOfNameChain
sys.Core.Relation.Seq
# The following are all regular sequence types.
sys.Core.Cat.NESeqOfName
These system-defined subtypes have also been defined for convenience, as they are anticipated to be frequently used; in fact, most of them are used as the declared parameter types of various core operators:
sys.Core.Universal.Universal
sys.Core.Universal.Empty
sys.Core.Scalar.Scalar
sys.Core.Ordered.Ordered
sys.Core.Int.Int
sys.Core.Int.UInt
sys.Core.Int.PInt
# The following are all finite integer types.
sys.Core.Spec.PInt1_4
sys.Core.Spec.PInt2_36
sys.Core.Relation.Relation
sys.Core.Relation.Set
# The following are all regular set types.
sys.Core.Spec.SetOfBool
sys.Core.Spec.SetOfInt
sys.Core.Spec.SetOfRat
sys.Core.Spec.SetOfBlob
sys.Core.Spec.SetOfText
# The following are all nonscalar type factories.
sys.Core.Spec.SetOfRelation
sys.Core.Relation.Maybe
# The following are all regular maybe types.
sys.Core.Spec.MaybeOfBool
sys.Core.Spec.MaybeOfInt
sys.Core.Spec.MaybeOfRat
sys.Core.Spec.MaybeOfBlob
sys.Core.Spec.MaybeOfText
sys.Core.Relation.Seq
# The following are all regular sequence types.
sys.Core.Spec.SeqOfBool
sys.Core.Spec.SeqOfInt
sys.Core.Spec.SeqOfRat
sys.Core.Spec.SeqOfBlob
sys.Core.Spec.SeqOfText
sys.Core.Relation.Bag
# The following are all regular bag types.
sys.Core.Spec.BagOfBool
sys.Core.Spec.BagOfInt
sys.Core.Spec.BagOfRat
sys.Core.Spec.BagOfBlob
sys.Core.Spec.BagOfText
# The following are all nonscalar type factories.
sys.Core.Spec.BagOfRelation
sys.Core.QuasiRelation.QuasiRelation
sys.Core.QuasiRelation.QuasiSet
# The following are all quasi-nonscalar type factories.
sys.Core.Spec.QuasiSetOfRelation
Note that, in later operator documentation, if you see something like
Foo{Bar} as a declared type, it corresponds to
sys.Core.Spec.FooOfBar.
These core data types are special and are the only Muldis D types that are neither scalar nor nonscalar nor quasi-nonscalar types. They are all system-defined and it is impossible for users to define more types of this nature.
The Universal type is the maximal type of the entire Muldis D type
system, and contains every value that can possibly exist. Every other type
is implicitly a proper subtype of Universal, and Universal is
implicitly a union type over all other types. Its default value is
Bool:false. The cardinality of this type is infinity.
The Empty type is the minimal type of the entire Muldis D type system,
and is the only type that contains exactly zero values. Every other type
is implicitly a proper supertype of Empty and Empty is implicitly an
intersection type over all other types. It has no default value. The
cardinality of this type is zero.
These are pseudo-types (that is, they aren't types at all) which represent generic contexts that could accept a multiplicity of types, but are not the same as contexts named after some actual types. For example, they are used as the declared parameter types of some dyadic polymorphic operators to refer to, per instance, 2 given types that need to be compatible, but the compatibility isn't simply defined by a ``are any 2 subtypes of'' such as is true with most operators. They are all system-defined and it is impossible for users to define more types of this nature.
Contexts defined by the Some.Universal pseudo-type accept values of
potentially any type of Universal.
Contexts defined by the Some.Ordered pseudo-type accept values of
potentially any type of Ordered.
These core scalar data types are the most fundamental Muldis D types. Each one has zero possreps, and hence has no named components that can be referenced. Concrete Muldis D provides a specific syntax per type to select a value of one of these types, which does not look like a routine invocation, but rather like a scalar literal in a typical programming language; details of that syntax are not given here, but in the Language::MuldisD::Grammar manpage. Abstract Muldis D as hosted in another language will essentially use literals of corresponding host language types, whatever they use for eg booleans and integers and character strings, but tagged with extra meta-data if the host language is more weakly typed or lacks one-to-one type correspondence; see the Language::MuldisD::PerlHosted manpage for a Perl-based example.
The Scalar type is the maximal type of all Muldis D scalar types, and
contains every scalar value that can possibly exist. Every other scalar
type is implicitly a proper subtype of Scalar, and Scalar is
implicitly a union type over all other scalar types. Its default value is
Bool:false. The cardinality of this type is infinity.
The Ordered type is a proper subtype of Scalar that is a proper
supertype of all scalar types that are considered ordered. Any scalar
types which consider themselves ordered, which happens to include every
system-defined core scalar root type, will explicitly declare themselves as
subtypes of Ordered in their type definitions; the definition of
Ordered does not specify what other types it is a union over. Its
default value is Bool:false. The cardinality of this type is infinity.
A Bool is an enumeration consisting of the 2 values Bool:false and
Bool:true. It represents a truth value, and is the result type of any
is_equal or is_not_equal routine; it is the only essential scalar
data type of a D language. Its default and minimum value is
Bool:false; its maximum value is Bool:true. The cardinality of this
type is 2.
An Order is an enumeration consisting of the 3 values Order:increase,
Order:same, Order:decrease. It is the result type of any compare
routine that is used on 2 values of a sys.Core.Ordered.Ordered subtype.
Its default value is Order:same; its minimum and maximum values are,
respectively, Order:increase and Order:decrease. The cardinality of
this type is 3.
An Int is a single exact integral number of any magnitude. Its default
value is zero; its minimum and maximum values are conceptually infinities
and practically impossible. The cardinality of this type is infinity; to
define a most-generalized finite Int subtype, you must specify the 2
integer end-points of the inclusive range that all its values are in.
A UInt (unsigned / non-negative integer) is a proper subtype of Int
where all member values are greater than or equal to zero. Its minimum
value is zero.
A PInt (positive integer) is a proper subtype of UInt where all
member values are greater than zero. Its default and minimum value is 1.
A Rat is a single exact rational number of any magnitude. It is
conceptually a numerator (Int) divided by a denominator (PInt).
Its default value is zero; its minimum and maximum values are conceptually
infinities and practically impossible. The cardinality of this type is
infinity; to define a most-generalized finite Rat subtype, you must
specify the greatest magnitude value denominator, plus the the 2 integer
end-points of the inclusive range of the value numerator. Common subtypes
specify that all denominators are positive powers of a particular radix
(PInt), where the radix is usually either 2 or 10; types such as these
will easily map exactly to common human or physical numeric
representations, so they tend to perform better.
A URat (unsigned / non-negative rational) is a proper subtype of Rat
where all member values are greater than or equal to zero. Its minimum
value is zero.
A PRat (positive integer) is a proper subtype of URat where all
member values are greater than zero. Its default value is 1.
A BRat (binary rational) is a proper subtype of Rat where the radix
is 2; it is the best option to exactly represent rational numbers that are
conceptually binary or octal or hexadecimal.
A DRat (decimal rational) is a proper subtype of Rat where the radix
is 10; it is the best option to exactly represent rational numbers that are
conceptually the decimal numbers that humans typically work with.
A Blob is an undifferentiated string of bits. Its default and minimum
value is the empty string; its maximum value is an infinite-length string
and practically impossible. The cardinality of this type is infinity; to
define a most-generalized finite Blob subtype, you must specify a
maximum length in bits that the subtype's strings are.
A NEBlob (non-empty blob) is a proper subtype of Blob where its
length in bits must be at least 1; it can be any Blob except for the
empty string. Its default and minimum value is a single zero bit.
A Text is a string of characters. Its default and minimum value is the
empty string; its maximum value is an infinite-length string and
practically impossible. Note that there is only one system-defined
character repertoire for Text types, which is the newest Unicode
repertoire (5.0.0). The cardinality of this type is infinity; to define a
most-generalized finite Text subtype, you must specify a maximum length
in characters (that is, eg, in NFC graphemes) that the subtype's strings
are.
A NEText (non-empty text) is a proper subtype of Text where its
length in characters must be more than zero; it can be any Text except
for the empty string. Its default value is a single ``space'' character; its
minimum value has one character, but which character that is depends on the
default or current collation.
These are only called nonscalar data types in a loose sense, because by themselves they are incomplete type definitions. Actual nonscalar data type definitions are derived from these by supplying the balance of the type definitions, such as what their attributes are and/or what their attribute types are. Associated with these incomplete type definitions are a set of system-defined routines that can be applied to values of any actual nonscalar types derived from them; such are called generic nonscalar operators. In the Muldis D type system, these incomplete nonscalar types are defined as union types over all actual types derived from them, and are proper supertypes of said.
Some actual nonscalar data types are system-defined, for use in defining the Muldis D system catalog / meta-model (see further below in the current document), and some others are system-defined for convenience since they are the types of many core operators (see further below in the current document), but all other actual nonscalar data types are user-defined. Users can also define their own incomplete nonscalar data types that are tuple or relation types.
The Tuple type is the maximal type of all Muldis D tuple (nonscalar)
types, and contains every tuple value that could possibly exist. A
Tuple is an unordered heterogeneous collection of 0..N named attributes
(the count of attributes being its degree), where all attribute names
are mutually distinct, and each attribute may be of distinct types; the
mapping of a tuple's attribute names and their declared data types is
called the tuple's heading. Its default value is the sole value of the
sole tuple data type that has zero attributes. The cardinality of this
type is equal to the product of the number of permutations drawable from
the values of each of its attributes' declared data types; for a Tuple
subtype to be finite, all of its attribute types must be.
A Database is a proper subtype of Tuple where all of its attributes
are each of relation types or of database types (the leaves of this
recursion are all relation types); it is otherwise the same.
The Relation type is the maximal type of all Muldis D relation
(nonscalar) types, and contains every relation value that could possibly
exist. A Relation is analogous to a set of 0..N tuples where all tuples
have the same heading (the degrees match and all attribute names and
corresponding declared data types match), but that a Relation data type
still has its own corresponding heading (attribute names and declared data
types) even when it consists of zero tuples. Its default value is the
zero-tuple value of the sole relation data type that has zero attributes.
Matters of its cardinality are generally the same as for Tuple. A
relation data type can also have (unique) keys each defined over a subset
of its attributes, which constrain its set of values relative to there
being no explicit keys, but having the keys won't turn an infinite relation
type into a finite one.
A Set is a proper subtype of Relation that has 1 attribute, and its
name is value; it can be of any declared type. A Set subtype is
normally used by any system-defined N-ary operators where the order of
their argument elements or result is not significant, and that duplicate
values are not significant. Its default value has zero tuples. Note that,
for any given complete Set subtype, Foo, where its value attribute
has a declared type of Bar, the type Foo can be considered the
power set of the type Bar.
A Maybe is a proper subtype of Set that may have at most one element;
that is, it is a unary Relation with a nullary key. Operators that work
specifically with Maybe subtypes can provide a syntactic shorthand for
working with sparse data; so Muldis D has something which is conceptually
close to SQL's nullable types without actually having 3-valued logic; it
would probably be convenient for code that round-trips SQL by way of Muldis
D to use the Maybe type. Its default value has zero tuples.
An Seq is a proper subtype of Relation that has 2 attributes, and
their names are index and value, where index is a unary key and
its declared type is an UInt subtype (value can be non-unique and of
any declared type). A Seq is considered dense, and all index values in
one are numbered consecutively from 0 to 1 less than the count of tuples,
like array indices in typical programming languages. A Seq subtype is
normally used by any system-defined N-ary operators where the order of
their argument elements or result is significant (and duplicate values are
significant); specifically, index defines an explicit ordering for
values. Its default value has zero tuples.
A Bag is a proper subtype of Relation that has 2 attributes, and
their names are value and count, where value is a unary key (that
can have any declared type) and count is a PInt subtype. A Bag
subtype is normally used by any system-defined N-ary operators where the
order of their argument elements or result is not significant, but that
duplicate values are significant; specifically, count defines an
explicit count of occurrences for values. Its default value has zero
tuples.
These quasi-nonscalar incomplete data type definitions correspond to their
similarly-named (differing only by the Quasi) nonscalar data types, and
their use is intended to be limited to the few situations where the
corresponding nonscalar data types can't be used. It should be noted in
particular that there is no ``QuasiDatabase'' type, since all normal data or
catalog databases should be composed of normal relations only; but all of
the other nonscalar incomplete types have counterparts here.
A QuasiTuple is like a Tuple but that the declared types of its
attributes can be anything at all. Its cardinality is infinite.
A QuasiRelation is like a Relation but that the declared types of its
attributes can be anything at all. Its cardinality is infinite.
A QuasiSet is a proper subtype of QuasiRelation in the corresponding
manner to Set being a proper subtype of Relation. Its cardinality is
infinite.
A QuasiMaybe is a proper subtype of QuasiRelation in the
corresponding manner to Maybe being a proper subtype of Relation.
Its cardinality is infinite.
A QuasiSeq is a proper subtype of QuasiRelation in the corresponding
manner to Seq being a proper subtype of Relation. Its cardinality is
infinite.
A QuasiBag is a proper subtype of QuasiRelation in the corresponding
manner to Bag being a proper subtype of Relation. Its cardinality is
infinite.
These core scalar data types are more special-purpose in nature and are intended for use in defining or working with the system catalog, which is mainly composed of nonscalar types built using these.
A Cat.ScalarLiteral is a union type over all the system-defined scalar
types that are allowed to be used directly as hard-coded literal values in
Muldis D expressions; 'directly' meaning not by way of explicitly invoking
a selector function. Generally speaking, this union type includes all of
the core scalar types that aren't themselves defined as union types. The
full list that ScalarLiteral unions is: Bool, Order, Int,
Rat, Blob, Text, Cat.Name, Cat.NameChain, Cat.E_TK,
Cat.E_TDM, Cat.E_EK, ...
A Cat.Name 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 Cat.Name,
depending on the context; other times, a Cat.NameChain must be used
instead to also qualify the reference with a namespace. Cat.Name is the
same as NEText in all ways but that it is specifically intended for use
in naming DBMS entities rather than being normal data.
A Cat.NameChain is a canonical long name for invoking or referring to a
DBMS entity, when its name needs to be qualified with a namespace. A
Cat.NameChain has 2 possreps; one possrep is a sequence of 1..N
Cat.Name (represented by a Cat.NESeqOfName), the 1..N elements being
ordered from parent-most to child-most component name; the other possrep is
a character string (represented by a Cat.FlattenedNameChain) like when
the elements of the first possrep are catenated (in order with the first
element at the start of the string), with a period (.) between the
parts, and each part escaped such that backslashes, single-quotes, and
periods are escaped as \b, \q and \p respectively.
The Cat.FlattenedNameChain type is used as the definition of the
character string possrep of a Cat.NameChain (see that type for details);
while being a character string like Cat.Name, the two are disjoint.
A Cat.E_TK (type kind) is an enumeration consisting of the 7 values
Cat.E_TK:special (mainly for system-defined implicit supertypes),
Cat.E_TK:scalar, Cat.E_TK:tuple, Cat.E_TK:relation,
Cat.E_TK:quasi_tuple, Cat.E_TK:quasi_relation, Cat.E_TK:remnant.
A Cat.E_TDM (type definition method) is an enumeration consisting of the
9 values Cat.E_TDM:special (for some system-defined types that don't
best fit in other categories, and all parameterized types; users can not
define the latter for now), Cat.E_TDM:root (complete root type defined
in terms of explicit attribute collection; all are fully defined, not
parameterized), Cat.E_TDM:restrict (defined as ``explicit other-type
where condition''), Cat.E_TDM:alias (so the same one type can have
multiple names), Cat.E_TDM:(union|intersection|exclusion) (defined as
explicit union|intersection|exclusion of other types),
Cat.E_TDM:difference (defined as explicit difference of 2 other types),
Cat.E_TDM:negation (defined as explicit negation of another type).
A Cat.E_EK (expression kind) is an enumeration consisting of the 8
values Cat.E_EK:default (default value of expression's type),
Cat.E_EK:(scalar|tuple|relation|quasi_tuple|quasi_relation) (hard-coded
literal scalar|tuple|relation|quasi-tuple|quasi-relation value),
Cat.E_EK:param (value of expression-containing function parameter),
Cat.E_EK:func (result of function invocation, or inlining of function
body). Its default value is Cat.E_EK:scalar.
These tuple data types, essentially all of the system-defined tuple types are special-purpose in nature and are intended for use in defining or working with the system catalog. They are all completely defined types.
Note that many of these types might conceptually have name attributes,
but those would actually be provided by any larger types in which they are
embedded, rather than by these types themselves.
Note that whenever an attribute of one of these 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.
To keep things simpler for now, most constraint definitions for these types are missing, or just defined informally.
A Cat.Type is a Tuple. It defines a data type, which can either be
(sometimes) invoked directly for values, or be invoked by or embedded into
other type definitions. Cat.Type is used in the catalogs for defining
both system and user types (just the interfaces in the former case).
A Cat.Type has these 7 attributes:
tk - Cat.E_TKtdm - Cat.E_TDMtk is Cat.E_TK:special, then tdm must be
Cat.E_TDM:special; tdm can be special at other times too.
types - Cat.SetOfNameChaintdm, the data type is defined at least partially in
terms of other data types not by way of attribute definitions, and then
types lists all/most of those types. Iff tdm is Cat.E_TDM:alias,
then the data type is just a symbolic reference for some other data type
(as far as the type system is concerned, they are the same data type,
invokable by an extra name), and types has one element that is the name
of that type. Iff tdm is Cat.E_TDM:restrict, then the data type is
defined as an explicit subtype of another type by way of an explicit
further type constraint applied to it, and types has one element that is
the name of that supertype. Iff tdm is
Cat.E_TDM:(union|intersection|exclusion), then the data type is defined
as an explicit union|intersection|exclusion of N other types, and types
lists their names, one per element; 2+ elements is the norm; just 1 element
means that the data type is a simple alias for the named element; zero
elements means the data type is a simple alias for, respectively, the type
Empty, Universal, or Empty. Iff tdm is
Cat.E_TDM.difference, then the data type is defined as the difference of
2 other types, and types has one element that is the name of the minuend
type. Iff tdm is Cat.E_TDM.negation, then the data type is defined
as the negation of some other type, and types has one element that is
the name of that type.
subtr_type - Cat.NameChaintdm is Cat.E_TDM.difference, then the data type is defined as the
difference of 2 other types, and subtr_type is the name of the
subtrahend type.
attrs - Cat.NameTypeMaptdm is Cat.E_TDM:root, then the data type is defined
fundamentally in terms of an explicit attribute collection, and attrs
defines the names and declared types of those attributes. Iff additionally
tk is Cat.E_TK:scalar, then attrs specifically defines the
attributes of just the core/initial/only possrep; otherwise, attrs
defines the heading of the tuple or relation etc type. It is valid to have
zero attributes; in this case, the type consists of exactly one value.
keys - Cat.SetOfSetOfNametk is Cat.E_TK:(relation|quasi_relation) and tdm is not
Cat.E_TDM:special, then the data type is or resembles a relation type
and can have explicit keys (duality of unique key constraints and terser
unique identifiers for the q/relation's member q/tuples) defined over its
attributes, and keys defines those keys in the canonical simplest form
(in contrast with using constraint instead). Each element of keys
defines one key of the q/relation, and that element is a set of the
attribute names comprising that key. For q/relation types, if no keys are
explicitly defined, then it implicitly has a single key comprising all of
its attributes. If any explicit keys 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 proper 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 q/relation type, and values of the type may each consist of no
more than one tuple.
constraint - Cat.TypeConstraint ... default one always ret Truetdm is Cat.E_TDM:root, then the data type is defined
fundamentally in terms of an explicit attribute collection, and
constraint defines/names a generalized type constraint that validates
the collection as a whole. Iff tdm is Cat.E_TDM:restrict, then the
data type is defined as an explicit subtype of another type by way of an
explicit further type constraint applied to it, and constraint
defines/names that further constraint.
The default value of Cat.Type is an alias of Empty.
A Cat.Expr is a Tuple. It specifies 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 Cat.Expr, either directly, or indirectly by way of
function invocations, as each function body is itself composed entirely of
a single expression tree. Only functions may contain Cat.Expr, so for
any procedures that would conceptually include them, those portions of the
procedures need to be separated out and encapsulated by named functions.
A Cat.Expr has these 8 attributes:
name - Cat.Nametype - Cat.NameChaintreat function
frequently in code, so that the programmer and compiler knows that some
generic routines are actually supposed to be returning a subtype of their
normal result types.
kind - Cat.E_EKscal_lit - Cat.ScalarLiteralkind is Cat.E_EK:scalar, then the expression represents a
hard-coded scalar literal of one of a certain collection of system-defined
core scalar types (or subtype thereof), and this is that literal value.
coll_lit - Cat.SetOfNameMapkind is Cat.E_EK:(|quasi_)(tuple|relation), then the expression
represents a collection literal, and these are the values of its
components. Each element defines one tuple, and each sub-element of that
element defines one attribute value for one tuple, with the sub-element
key matching the attribute name, and the sub-element value naming
another local Cat.Expr which defines the value. The value of
coll_lit defines exactly one tuple when kind specifies a tuple or
quasi-tuple, and it defines 0..N tuples when kind specifies a relation
or quasi-relation.
param - Cat.Namekind is Cat.E_EK:param, then the expression represents the value
of the containing function's parameter which this names.
func - Cat.NameChainkind is Cat.E_EK:func, then the expression represents the result
of invoking a named function with specific arguments, and this the name of
that function.
func_args - Cat.NameMapfunc is used, then these are the arguments for the function
invocation. Each element defines one argument value, with the element
key matching the parameter name, and the element value naming another
local Expr which defines the value.
The default value of Cat.Expr represents the literal scalar value
Bool:false.
TODO.
These relation data types, essentially all of the system-defined relation types are special-purpose in nature and are intended for use in defining or working with the system catalog. They are all completely defined types.
To keep things simpler for now, most constraint definitions for these types are missing, or just defined informally.
A Cat.NameTypeMap is a Relation. It defines a basic component list,
meaning a set of names, with a declared data type for each. It forms the
foundation for most componentized type definitions, including all tuple and
relation types (for which it is named 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 Cat.NameTypeMap has 2 attributes,
name (a Cat.Name) and type (a Cat.NameChain); the name is
the declared name of the attribute or parameter, and comprises a unary key;
the type is the declared data type of the attribute or parameter. Its
default value has zero tuples.
A Cat.NameMap specifies a map of short entity names to other short
entity names. It is a binary Relation whose 2 attributes are named
key and value, and both attributes have declared types of
Cat.Name; the key attribute is a unary key. Its default value
has zero tuples.
A Cat.BiDiNameMap is a proper subtype of Cat.NameMap where
its value attribute is also a unary key. It is used as a specification
for how to rename attributes of a relation.
A Cat.SetOfName is a (Set) whose value attribute has a
declared type of Cat.Name.
A Cat.SetOfSetOfName is a (Set) whose value attribute has a
declared type of Cat.SetOfName.
A Cat.SetOfNameMap is a (Set) whose value attribute has a
declared type of Cat.NameMap.
A Cat.SetOfNameChain is a (Set) whose value attribute has a
declared type of Cat.NameChain.
A Cat.NESeqOfName is a (Seq) whose value attribute has a declared
type of Cat.Name and that must have at least 1 element; this type is
used as the definition of the sequence possrep of a Cat.NameChain (see
that type for details).
These types are proper subtypes of other core types, and they are system-defined for convenience, as they are anticipated to be frequently used; in fact, most of them are used as the declared parameter types of various core operators.
sys.Core.Spec.PInt1_4PInt1_4 is a proper subtype of PInt where all member values are
between 1 and 4. Its maximum value is 4. The cardinality of this type is
4.
sys.Core.Spec.PInt2_36PInt2_36 is a proper subtype of PInt where all member values are
between 2 and 36. (The significance of the number 36 is 10 digits plus 26
letters.) Its default and minimum value is 2; its maximum value is 36.
The cardinality of this type is 35.
sys.Core.Spec.(Set|Maybe|Seq|Bag)Of(Bool|Int|Rat|Blob|Text)(Set|Maybe|Seq|Bag)Of(Bool|Int|Rat|Blob|Text) is a completely defined
proper subtype of (Set|Maybe|Seq|Bag) whose value attribute has a
declared type of a (Bool|Int|Rat|Blob|Text) subtype.
sys.Core.Spec.(Set|Bag)OfRelation(Set|Bag)OfRelation is an incompletely defined proper subtype of
Set|Bag whose value attribute has a declared type of a Relation
subtype.
sys.Core.Spec.QuasiSetOfRelationQuasiSetOfRelation is an incompletely defined proper subtype of
QuasiSet whose value attribute has a declared type of Relation;
this is the parameter type of the N-ary relational join operator.
These functions are applicable to values of any data type at all.
sys.Core.Universal.is_equal of Bool (Some.Universal $v1,
Some.Universal $v2)Bool:true iff its 2 arguments are exactly the
same value, and Bool:false otherwise. This function's arguments must be
of compatible declared types; in this case, 2 declared types are compatible
iff at least one of the following is true: 1. they are both subtypes of a
common scalar root type; 2. they are both subtypes of a common
non-incomplete tuple or relation type, that is they essentially have the
same headings; 3. at least one type is a generic (eg-Universal) or
incomplete (eg-Seq) type, and it is a supertype of the other. This
function is commutative.
sys.Core.Universal.is_not_equal of Bool (Some.Universal $v1,
Some.Universal $v2)sys.Core.Universal.is_equal except
that it results in the opposite boolean value when given the same
arguments.
sys.Core.Universal.is_value_of_type of Bool (Cat.NameChain $type,
Universal $v)Bool:true iff the value of its $v argument
is a member of the data type whose name is given in the $type argument,
and Bool:false otherwise. As trivial cases, this function always
results in Bool:true if the named type is Universal, and
Bool:false if it is Empty. This function will fail if the named type
doesn't exist in the virtual machine.
sys.Core.Universal.treat of Some.Universal (Cat.NameChain $as,
Some.Universal $v)$v argument, but that the
declared type of the result is the not-Empty data type whose name is
given in the $as argument. This function will fail if the named type
doesn't exist in the virtual machine, or if $v isn't a member of the
named type. The purpose of treat is to permit taking values from a
context having a more generic declared type, and using them in a context
having a more specific declared type; such an action would otherwise be
blocked at compile time due to a type-mismatch error; treat causes the
type-mismatch validation, and possible failure, to happen at runtime
instead, on the actual value rather than declared value. For example, if
you are storing an Int value in a Scalar-typed variable, using
treat will cause the compiler to let you use that variable as an
argument to Int.sum, which it otherwise wouldn't.
sys.Core.Universal.default of Some.Universal (Cat.NameChain $of)Empty data type
whose name is given in the $of argument, and the declared type of the
result is that same type. This function will fail if the named type
doesn't exist in the virtual machine, either at compile or runtime
depending whether the type is in the system or user namespace. This
function is conceptually implicitly used to provide default values for
variables, so they always hold valid values of their declared type.
These functions are applicable to values of any data type which is a
subtype of Ordered. They provide a common syntax for sort-related
functionality, though technically every type having these functions is
re-implementing its own version. If values of an ordered data type can
conceivably be sorted using multiple criteria (such as different text
collations), then these functions just represent the default criteria; any
additional criteria are represented by additional functions declared for
just the types they apply to.
sys.Core.Ordered.compare of Order (Some.Ordered $v1, Some.Ordered
$v2)Order:same iff its 2 arguments are exactly the
same value, and otherwise it results in Order:increase if the value of
the $v2 argument is considered to be an increase (as defined by the
type) over the value of the $v1 argument, and otherwise it results in
Order:decrease as the reverse of the last condition would be true. This
function's arguments must be of compatible declared types; in this case, 2
declared types are compatible iff they are both subtypes of a common scalar
type that declares itself an Ordered subtype. Note that compare is
considered the only fundamental ordered-specific operator, and all others
are defined over it.
sys.Core.Ordered.reverse_compare of Order (Some.Ordered $v1,
Some.Ordered $v2)sys.Core.Ordered.compare except
that it results in the reverse value when given the same arguments. It is
a short-hand for applying sys.Core.Order.reverse to the result of
sys.Core.Ordered.compare with the same arguments.
sys.Core.Ordered.is_increase of Bool (Some.Ordered $v1,
Some.Ordered $v2)Bool:true iff sys.Core.Ordered.compare would
result in Order:increase when given the same arguments, and
Bool:false otherwise.
sys.Core.Ordered.is_decrease of Bool (Some.Ordered $v1,
Some.Ordered $v2)Bool:true iff sys.Core.Ordered.compare would
result in Order:decrease when given the same arguments, and
Bool:false otherwise.
sys.Core.Ordered.min of Some.Ordered (Set{Some.Ordered} $topic)$topic has zero values, then min results in
the result type's concept of positive infinity, which is the identity value
for min. This function will fail on a $topic of zero values if the
result type's concept of positive infinity is impossible or impractically
large to represent, such as with the infinite Text type.
sys.Core.Ordered.max of Some.Ordered (Set{Some.Ordered} $topic)sys.Core.Ordered.min except that it
results in the maximum input element value rather than the minimum one, and
its identity value is the result type's concept of negative infinity.
sys.Core.Ordered.maybe_min of Maybe{Some.Ordered}
(Set{Some.Ordered} $topic)sys.Core.Ordered.min except that it
results in a Maybe of what is otherwise the result type, and that result
has zero elements if the argument has zero elements.
sys.Core.Ordered.maybe_max of Maybe{Some.Ordered}
(Set{Some.Ordered} $topic)sys.Core.Ordered.max as
sys.Core.Ordered.maybe_min is to sys.Core.Ordered.min.
These functions are applicable to just one or more specific system-defined core scalar data type.
These functions select values of the Bool enumeration.
sys.Core.Bool.(false|true) of Bool ()Bool:(false|true) value.
These functions implement commonly used boolean operations.
sys.Core.Bool.not of Bool (Bool $topic)sys.Core.Bool.and of Bool (Set{Bool} $topic)$topic has zero values, then and results in
Bool:true, which is the identity value for logical and.
sys.Core.Bool.or of Bool (Set{Bool} $topic)$topic has zero values, then or results in
Bool:false, which is the identity value for logical inclusive-or.
sys.Core.Bool.xor of Bool (Bag{Bool} $topic)$topic has zero values, then xor results in
Bool:false, which is the identity value for logical exclusive-or.
These functions select values of the Order enumeration.
sys.Core.Order.(increase|same|decrease) of Order ()Order:(increase|same|decrease)
value.
These functions implement commonly used order-enumeration operations.
sys.Core.Order.reverse of Order (Order $topic)Order:increase or Order:decrease argument results in the other one of
the two; an Order:same argument results in Order:same.
These functions implement commonly used integer numeric operations.
sys.Core.Int.abs of UInt (Int $topic)sys.Core.Int.sum of Int (Bag{Int} $addends)$addends has zero values,
then sum results in the integer zero, which is the identity value for
addition.
sys.Core.Int.difference of Int (Int $minuend, Int $subtrahend)$subtrahend argument is
subtracted from its $minuend argument.
sys.Core.Int.product of Int (Bag{Int} $factors)$factors
has zero values, then product results in the integer 1, which is the
identity value for multiplication.
sys.Core.Int.quotient of Int (Int $dividend, Int $divisor)$dividend argument is
divided by its $divisor argument using integer division. This function
will fail if $divisor is zero.
sys.Core.Int.remainder of UInt (Int $dividend, Int $divisor)$dividend argument is
divided by its $divisor argument using integer division. This function
will fail if $divisor is zero.
sys.Core.Int.maybe_quotient of Maybe{Int} (Int $dividend, Int
$divisor)sys.Core.Int.quotient except that
it results in a Maybe of what is otherwise the result, and that result
has zero elements if $divisor is zero.
sys.Core.Int.maybe_remainder of Maybe{UInt} (Int $dividend, Int
$divisor)sys.Core.Int.remainder except that
it results in a Maybe of what is otherwise the result, and that result
has zero elements if $divisor is zero.
sys.Core.Int.range of Int (Set{Int} $topic)$topic has zero values, then
range results in the integer zero.
sys.Core.Int.median of Set{Int} (Bag{Int} $topic)$topic has
zero values, then the result set is empty.
sys.Core.Int.mode of Set{Int} (Bag{Int} $topic)$topic has zero values, then the result set is empty.
sys.Core.Int.power of Int (Int $radix, UInt $exponent)$radix argument taken to the power of its
(unsigned integer) $exponent argument. This function will fail if
$radix and $exponent are both zero.
These functions convert between Int values and canonically formatted
representations of integers as character strings.
sys.Core.Int.Int_from_NEText of Int (NEText $text, PInt2_36
$radix)Int value that its $text
argument maps to when the whole character string is evaluated as a
base-$radix integer. Extending the typical formats of [base-2, base-8,
base-10, base-16], this function supports base-2 through base-36; to get
the latter, the characters 0-9 and A-Z represent values in 0-35. This
function will fail if $text can't be mapped as specified.
sys.Core.Int.NEText_from_Int of NEText (Int $int, PInt2_36 $radix)NEText value where its $int
argument is formatted as a base-$radix integer.
These functions convert between Int values and canonically formatted
representations of integers as binary strings. Conjecture: These may not
actually be useful, and perhaps only operators that take an argument
specifying a fixed-length field size, with big and little endian versions,
would be appropriate instead. Or maybe both kinds are necessary.
sys.Core.Int.Int_from_Blob_S_VBE of Int (NEBlob $blob)Int value that its $blob
argument maps to when the whole bit string is treated literally as a
variable-length binary (two's complement) signed integer of 1 or more bits
in length. The first bit is taken as the sign bit, and any other bits
provide greater precision than the -1 thru 0 range. The bit string is
assumed to be big-endian, since it may not be possible to use little-endian
in situations where the bit length isn't a multiple of 8.
sys.Core.Int.Blob_S_VBE_from_Int of NEBlob (Int $int)Blob value where its $int
argument is formatted as a variable-length binary (two's complement) signed
integer of 1 or more bits in length; the smallest number of bits necessary
to store $int is used.
sys.Core.Int.Int_from_Blob_U_VBE of UInt (NEBlob $blob)sys.Core.Int.Int_from_Blob_S_VBE but that
it does unsigned integers.
sys.Core.Int.Blob_U_VBE_from_Int of UInt (NEBlob $blob)sys.Core.Int.Blob_S_VBE_from_Int but that
it does unsigned integers.
These functions are essentially selectors and attribute extractors for the conceptual possrep of a rational in terms of an integral numerator plus denominator.
sys.Core.Rat.Rat_from_Int_pair of Rat (Int $numerator, PInt
$denominator)Rat value that its $numerator
and $denominator arguments map to when collectively interpreted in the
appropriate fashion, as if there were a possrep for the Rat type that
was composed of such 2 attributes, but keeping in mind that multiple
distinct argument pairs can map to each same Rat value, since the
arguments don't have to be a canonical pair.
sys.Core.Rat.numerator of Int (Rat $topic)sys.Core.Rat.denominator of PInt (Rat $topic)These functions implement commonly used rational numeric operations.
sys.Core.Rat.abs of URat (Rat $topic)sys.Core.Rat.sum of Rat (Bag{Rat} $addends)$addends has zero values,
then sum results in the rational zero, which is the identity value for
addition.
sys.Core.Rat.difference of Rat (Rat $minuend, Rat $subtrahend)$subtrahend argument is
subtracted from its $minuend argument.
sys.Core.Rat.product of Rat (Bag{Rat} $factors)$factors
has zero values, then product results in the rational 1, which is the
identity value for multiplication.
sys.Core.Rat.quotient of Rat (Rat $dividend, Rat $divisor)$dividend argument is
divided by its $divisor argument using rational division. This function
will fail if $divisor is zero.
sys.Core.Rat.maybe_quotient of Maybe{Rat} (Rat $dividend, Rat
$divisor)sys.Core.Rat.quotient except that
it results in a Maybe of what is otherwise the result, and that result
has zero elements if $divisor is zero.
sys.Core.Rat.range of Rat (Set{Rat} $topic)$topic has zero values, then
range results in the rational zero.
sys.Core.Rat.mean of Rat (Bag{Rat} $topic)$topic has zero values, then this function will fail.
sys.Core.Rat.maybe_mean of Maybe{Rat} (Bag{Rat} $topic)sys.Core.Rat.mean except that it
results in a Maybe of what is otherwise the result, and that result has
zero elements if $topic has zero values.
sys.Core.Rat.median of Set{Rat} (Bag{Rat} $topic)$topic has
zero values, then the result set is empty.
sys.Core.Rat.mean_of_median of Rat (Bag{Rat} $topic)sys.Core.Rat.median that will return the
mean of its result elements; it will fail if there are zero elements.
sys.Core.Rat.mode of Set{Rat} (Bag{Rat} $topic)$topic has zero values, then the result set is empty.
sys.Core.Rat.power of PRat (PRat $radix, Rat $exponent)$radix argument taken
to the power of its $exponent argument. Note that, while this function
might conceptually have multiple real number results for some negative
$exponent, it will always only return the one that is positive.
sys.Core.Rat.log of Rat (PRat $topic, PRat $radix, PInt
$rebase_radix, PInt $rebase_max_denom, Cat.RoundMeth $rebase_round)$topic argument to the
base given in its (positive rational) $radix argument. Since the result
would be an irrational number in the general case, the additional 3
$rebase_\w+ parameters specify how to coerce the conceptual result into
a rational number that is the actual result; see also the similarly named
parameters of the sys.Core.Rat.rebase function.
sys.Core.Rat.natural_power of PRat (Rat $exponent, PInt
$rebase_radix, PInt $rebase_max_denom, Cat.RoundMeth $rebase_round)$exponent
argument. The 3 $rebase_\w+ parameters are as per log.
sys.Core.Rat.natural_log of Rat (PRat $topic, PInt $rebase_radix,
PInt $rebase_max_denom, Cat.RoundMeth $rebase_round)$topic argument.
The 3 $rebase_\w+ parameters are as per log.
These functions convert between Rat values and canonically formatted
representations of rationals as character strings.
sys.Core.Rat.Rat_from_NEText of Rat (NEText $text, PInt2_36
$radix)Rat value that its $text
argument maps to when the whole character string is evaluated as a
base-$radix rational. Extending the typical formats of [base-2, base-8,
base-10, base-16], this function supports base-2 through base-36; to get
the latter, the characters 0-9 and A-Z represent values in 0-35. This
function will fail if $text can't be mapped as specified.
sys.Core.Rat.NEText_from_Rat of NEText (Rat $rat, PInt2_36 $radix)NEText value where its $rat
argument is formatted as a base-$radix rational.
These functions convert between Rat values and equal or nearly equal
Int values.
sys.Core.Rat.Rat_from_Int of Rat (Int $int)Rat value that is conceptually
equal to its Int argument.
sys.Core.Rat.round_half_up of Int (Rat $topic)sys.Core.Rat.round_to_even of Int (Rat $topic)sys.Core.Rat.round_to_floor of Int (Rat $topic)sys.Core.Rat.round_to_ceiling of Int (Rat $topic)sys.Core.Rat.round_to_zero of Int (Rat $topic)These functions round and/or truncate rational values to make them easier to deal with in various contexts.
sys.Core.Rat.rebase of Rat (Rat $topic, PInt $radix, PInt
$max_denom, Cat.RoundMeth $round)$topic but that its denominator is a positive power of $radix and
said denominator is not larger than $max_denom; if rounding is needed,
then $round dictates the rounding method.
These functions implement commonly used binary string operations.
sys.Core.Blob.catenate of Blob (Seq{Blob} $topic)$topic has
zero values, then catenate results in the empty string value, which is
the identity value for catenate.
sys.Core.Blob.repeat of Blob (Blob $topic, UInt $count)$count instances of
$topic.
sys.Core.Blob.length_in_bits of UInt (Blob $topic)sys.Core.Blob.contains of Bool (Blob $look_in, Blob $look_for, Bool
$fixed_start, Bool $fixed_end)Bool:true iff its $look_for argument is a
substring of its $look_in argument as per the optional $fixed_start
and $fixed_end constraints, and Bool:false otherwise. If
$fixed_start or $fixed_end are Bool:true, then $look_for must
occur right at the start or end, respectively, of $look_in in order for
contains to results in Bool:true; if either flag is Bool:false,
its additional constraint doesn't apply.
sys.Core.Blob.not of Blob (Blob $topic)sys.Core.Blob.and of Blob (Set{Blob} $topic)Blob subtype) definition, and that is also the length in bits
of the function's result. If $topic has zero values, then and will
result in an appropriate-length string of identity/1 valued bits.
sys.Core.Blob.or of Blob (Set{Blob} $topic)sys.Core.Blob.and but that it recursively
does a bitwise inclusive-or rather than a bitwise and, and its identity
value is composed of zero valued bits.
sys.Core.Blob.xor of Blob (Bag{Blob} $topic)sys.Core.Blob.or but that it recursively
does a bitwise exclusive-or rather than a bitwise inclusive-or.
These functions convert between Blob values and canonically formatted
representations of binary strings as character strings.
sys.Core.Blob.Blob_from_Text of Blob (Text $text, PInt1_4 $size)Blob value that its $text
argument maps to when each input character represents a sequence of 1-4
bits, the number of bits per character being determined by the $size
argument; for example, if $size is 1, then each input character is a
[0-1] and represents a bit; or, if $size is 4, then each input character
is a [0-9A-F] and represents 4 bits. This function will fail if $text
can't be mapped as specified.
sys.Core.Blob.Text_from_Blob of Text (Blob $blob, PInt1_4 $size)Text value where its argument is
encoded using a character for each sequence of 1-4 bits, the number of bits
per character being determined by the $size argument. This function
will fail if $blob doesn't have a length in bits which is a multiple of
$size.
These functions implement commonly used character string operations.
sys.Core.Text.catenate of Text (Seq{Text} $topic)$topic has
zero values, then catenate results in the empty string value, which is
the identity value for catenate.
sys.Core.Text.repeat of Text (Text $topic, UInt $count)$count instances of
$topic.
sys.Core.Text.length_in_nfd_graphs of UInt (Text $topic)sys.Core.Text.length_in_nfc_graphs of UInt (Text $topic)sys.Core.Text.length_in_nfd_codes of UInt (Text $topic)sys.Core.Text.length_in_nfc_codes of UInt (Text $topic)sys.Core.Text.contains of Bool (Text $look_in, Text $look_for, Bool
$fixed_start, Bool $fixed_end)Bool:true iff its $look_for argument is a
substring of its $look_in argument as per the optional $fixed_start
and $fixed_end constraints, and Bool:false otherwise. If
$fixed_start or $fixed_end are Bool:true, then $look_for must
occur right at the start or end, respectively, of $look_in in order for
contains to result in Bool:true; if either flag is Bool:false, its
additional constraint doesn't apply.
sys.Core.Text.fold_case_to_upper (Text $topic)sys.Core.Text.fold_case_to_lower (Text $topic)sys.Core.Text.trim_whitespace (Text $topic)
These functions are applicable to mainly nonscalar types, but are generic in that they typically work with any nonscalar types.
sys.Core.Tuple.degree of UInt (Tuple $topic)sys.Core.Tuple.rename of Tuple (Tuple $topic, Cat.BiDiNameMap
$map)Tuple value that is the same as its $topic
argument but that some of its attributes have different names. Each tuple
of the argument $map specifies how to rename one $topic attribute,
with the key and value attributes of a $map tuple representing the
old and new names of a $topic attribute, respectively. As a trivial
case, this function's result is $topic if $map has no tuples. This
function supports renaming attributes to each others' names. This function
will fail if $map specifies any old names that $topic doesn't have,
or any new names that are the same as $topic attributes that aren't
being renamed.
sys.Core.Tuple.project of Tuple (Tuple $topic, Cat.SetOfName
$attrs)$topic argument that has
just the subset of attributes of $topic which are named in its $attrs
argument. As a trivial case, this function's result is $topic if
$attrs lists all attributes of $topic; or, it is the nullary tuple if
$attrs is empty. This function will fail if $attrs specifies any
attribute names that $topic doesn't have.
sys.Core.Tuple.remove of Tuple (Tuple $topic, Cat.SetOfName
$attrs)project but that it results in the
complementary subset of attributes of $topic when given the same
arguments.
sys.Core.Tuple.wrap of Tuple (Tuple $topic, Cat.SetOfName
$inner, Cat.Name $outer)Tuple value that is the same as its $topic
argument but that some of its attributes have been wrapped up into a new
Tuple-typed attribute, which exists in place of the original attributes.
The $inner argument specifies which $topic attributes are to be
removed and wrapped up, and the $outer argument specifies the name of
their replacement attribute. As a trivial case, if $inner is empty,
then the result has all the same attributes as before plus a new nullary
tuple attribute; or, if $inner lists all attributes of $topic, then
the result has a single attribute whose value is the same as $topic.
This function supports the new attribute having the same name as an old one
being wrapped into it. This function will fail if $inner specifies any
attribute names that $topic doesn't have, or if $outer is the same as
$topic attributes that aren't being wrapped.
sys.Core.Tuple.unwrap of Tuple (Tuple $topic, Cat.Name
$outer)sys.Core.Tuple.wrap, such that it will
unwrap a Tuple-type attribute into its member attributes. This function
will fail if $outer specifies any attribute name that $topic doesn't
have, or if an attribute of $topic{$outer} is the same as a $topic
attribute.
sys.Core.Tuple.product of Tuple (QuasiSet{Tuple} $topic)sys.Core.Relation.product but that it works
with tuples rather than relations. This function is mainly intended for
use in connecting tuples that have all disjoint headings, such as for
extending one tuple with additional attributes.
sys.Core.Relation.degree of UInt (Relation $topic)sys.Core.Relation.cardinality of UInt (Relation $topic)sys.Core.Relation.is_empty of Bool (Relation $topic)Bool:true iff its argument has zero tuples, and
Bool:false otherwise. Note that if you are using a Maybe to
represent a sparse data item, analagously to a SQL nullable context, then
testing the Maybe with is_empty is analagous to testing a SQL
nullable with is null.
sys.Core.Relation.is_not_empty of Bool (Relation $topic)sys.Core.Relation.empty except that
it results in the opposite boolean value when given the same argument. And
following the analogy with is_empty, is_not_empty is analagous to
SQL's is not null.
sys.Core.Relation.exists of Bool (Relation $r, Tuple $t)Bool:true iff its $t argument matches a
tuple of its $r argument, and Bool:false otherwise. This function is
like sys.Core.Relation.contains except that the tuple being looked for
doesn't have to be wrapped in a relation. This function will fail if the 2
arguments don't have the same heading.
sys.Core.Relation.Tuple_from_Relation of Tuple (Relation $topic)Tuple that is the sole member tuple of its
argument. This function will fail if its argument does not have exactly
one tuple.
sys.Core.Relation.Relation_from_Tuple of Relation (Tuple $topic)Relation value those body has just the one
Tuple that is its argument.
sys.Core.Relation.insert of Relation (Relation $r, Tuple $t)Relation that is the relational union of
$r and a relation whose sole tuple is $t; that is, conceptually the
result is $t inserted into $r. As a trivial case, if $t already
exists in $r, then the result is just $r.
sys.Core.Relation.delete of Relation (Relation $r, Tuple $t)Relation that is the relational difference of
a relation whose sole tuple is $t and $r; that is, conceptually the
result is $t deleted from $r. As a trivial case, if $t already
doesn't exist in $r, then the result is just $r.
sys.Core.Relation.evacuate of Relation (Relation $topic)Relation that has the same heading as its
argument, but with an empty body.
sys.Core.Relation.negation of Relation (Relation $topic)sys.Core.Relation.rename of Relation (Relation $topic,
Cat.BiDiNameMap $map)sys.Core.Tuple.rename but that it operates
on and results in a Relation rather than a Tuple.
sys.Core.Relation.project of Relation (Relation $topic,
Cat.SetOfName $attrs)sys.Core.Tuple.project but that it operates
on and results in a Relation rather than a Tuple. But note that the
result relation will have fewer tuples than $topic if any $topic
tuples were non-distinct for just the projected attributes.
sys.Core.Relation.remove of Relation (Relation $topic,
Cat.SetOfName $attrs)sys.Core.Tuple.remove but that it operates
on and results in a Relation rather than a Tuple.
sys.Core.Relation.wrap of Relation (Relation $topic,
Cat.SetOfName $inner, Cat.Name $outer)sys.Core.Tuple.wrap but that it operates on
and results in a Relation rather than a Tuple, where each of its
member tuples was transformed as per sys.Core.Tuple.wrap.
sys.Core.Relation.unwrap of Relation (Relation $topic,
Cat.Name $outer)sys.Core.Relation.wrap as
sys.Core.Tuple.unwrap is to sys.Core.Tuple.wrap.
sys.Core.Relation.group of Relation (Relation $topic,
Cat.SetOfName $inner, Cat.Name $outer)sys.Core.Relation.ungroup of Relation (Relation $topic,
Cat.Name $outer)sys.Core.Relation.tclose of Relation (Relation $topic)tclose
will determine all of the node pairs in that graph which have a path
between them (a recursive operation), so each tuple of the result
represents a path. The result is a superset since all arcs are also
complete paths. The tclose function is intended to support recursive
queries, such as in connection with the ``part explosion problem'' (the
problem of finding all components, at all levels, of some specified part).
sys.Core.Relation.restrict of Relation (Relation $topic,
Cat.NameChain $func, Tuple $assuming)$topic
argument as determined by applying the Bool-returning function named in
its $func argument when the latter function is curried by its
$assuming argument. The result relation has the same heading as
$topic, and its body contains the subset of $topic tuples where, for
each tuple, the function named by $func results in Bool:true when
passed the tuple as its $topic argument and $assuming as its
$assuming argument. As a trivial case, if $func is defined to
unconditionally result in Bool:true, then this function results simply
in $topic; or, for an unconditional Bool:false, this function results
in the empty relation with the same heading. Note that this operation is
also legitimately known as where. Note that
sys.Core.Relation.semijoin is recommended for use instead of
sys.Core.Relation.restrict to implement some common kinds of relational
restrictions (those composed simply of anded or ored tests for attribute
value equality), due to the former's greater simplicity.
sys.Core.Relation.extend of Relation (Relation $topic,
Cat.NameChain $func, Tuple $assuming)$topic
argument, but that it has zero or more additional attributes, as determined
by applying the Tuple-returning function named in its $func argument
when the latter function is curried by its $assuming argument. The
result relation has a heading that is a superset of that of $topic, and
its body contains the same number of tuples, with all attribute values of
$topic retained, and possibly extra present, determined as follows; for
each $topic tuple, the function named by $func results in a second
tuple when passed the first tuple as its $topic argument and
$assuming as its $assuming argument; the first and second tuples have
no attribute names in common, and the result tuple is derived by joining
the tuples together.
sys.Core.Relation.summarizesys.Core.Relation.substitute
sys.Core.Relation.contains of Bool (Relation $look_in, Relation
$look_for)Bool:true iff the set of tuples comprising
$look_for is a subset of the set of tuples comprising $look_in, and
Bool:false otherwise. This function will fail if the 2 arguments don't
have the same heading.
sys.Core.Relation.union of Relation (Set{Relation} $topic)$topic has zero values, then union results in the empty relation
with the same heading, which is the per-distinct-heading identity value for
relational union.
sys.Core.Relation.exclusion of Relation (Bag{Relation} $topic)$topic has zero values, then exclusion results
in the empty relation with the same heading, which is the
per-distinct-heading identity value for relational exclusion. Note that
this operation is also legitimately known as symmetric difference, or
disjoint union.
sys.Core.Relation.intersection of Relation (Set{Relation} $topic)$topic has zero values, then intersection results in
the universal relation with the same heading (that is, the relation having
all the tuples that could ever exist in a relation with that heading),
which is the per-distinct-heading identity value for relational
intersection. Note that this intersection operator is conceptually a
special case of join, applicable when the headings of the inputs are the
same, and the other will produce the same result as this when given the
same inputs, but with the exception that intersection has a different
identity value when given zero inputs. This function will fail on a
$topic of zero values if the result type's universal relation is
impossible or impractically large to represent, such as when any attributes
are of infinite types.
sys.Core.Relation.difference of Relation (Relation $source,
Relation $filter)$filter
argument is subtracted from its $source argument. The result relation
has the same heading as both of its arguments, and its body contains only
the tuples that are in $source and are not in $filter. This function
will fail if its 2 arguments do not have the same heading. Note that this
difference operator is conceptually a special case of semidifference,
applicable when the headings of the inputs are the same.
sys.Core.Relation.semidifference of Relation (Relation $source,
Relation $filter)semijoin but that it results in the
complementary subset of tuples of $source when given the same arguments.
Note that this operation is also legitimately known as antijoin.
sys.Core.Relation.semijoin of Relation (Relation $source, Relation
$filter)$source and
$filter arguments. The result relation has the same heading as
$source, and its body contains the subset of $source tuples that
match those of $filter as per join. Note that relational semijoin is
conceptually a short-hand for first doing an ordinary relational join
between its 2 arguments, and then performing a relational projection on all
of the attributes that just $source has. This function will fail any
time that join would fail on the same 2 input relations.
sys.Core.Relation.join of Relation (QuasiSet{Relation} $topic)$topic has zero values, then join results in
the nullary relation with one tuple, which is the identity value for
relational join. As a trivial case, if any input relation has zero tuples,
then the function's result will too; or, if any input is the nullary
relation with one tuple, that input can be ignored (see identity value);
or, if any 2 inputs have no attribute names in common, then the join of
just those 2 is a cartesian product; or, if any 2 inputs have all attribute
names in common, then the join of just those 2 is an intersection; or, if
for 2 inputs, one's set of attribute names is a proper subset of another's,
then the join of just those to is a semijoin with the former filtering the
latter. This function will fail if any input relations have attributes
with common names but different/incompatible declared types. Note that
this operation is also legitimately known as natural inner join.
sys.Core.Relation.product of Relation (QuasiSet{Relation} $topic)join where all input relations have mutually distinct attribute names;
unlike join, product will fail if any inputs have attribute names in
common. Note that this operation is also legitimately known as
cartesian/cross join.
sys.Core.Relation.compose of Relation (Relation $r1, Relation $r2)join
would fail on the same 2 input relations.
sys.Core.Relation.quotient of Relation (Relation $dividend,
Relation $divisor)$dividend argument is
divided by its $divisor argument using relational division. Speaking
informally, say the relations $dividend and $divisor are called A
and B, and their attribute sets are respectively named {X,Y} and
{Y}, then the result relation has a heading composed of attributes
{X} (so the result and $divisor headings are both complementary
subsets of the $dividend heading); the result has all tuples {X} such
that a tuple {X,Y} appears in A for all tuples {Y} appearing in
B; that is, A / B is shorthand for A{X} - ((A{X} join B) - A){X}.
This documentation is pending.
These update operators are applicable to values of any data type at all.
sys.Core.Universal.assign (UPD: Some.Universal $target ; RO:
Some.Universal $v)$target
argument so that it holds the value supplied as its $v argument. This
update operator's arguments must be of compatible declared types; in this
case, $v must be a subtype of $target.
These update operators are applicable to just one or more specific system-defined core scalar data type.
This documentation is pending.
These update operators are applicable to mainly nonscalar types, but are generic in that they typically work with any nonscalar types.
This documentation is pending.
These system services are applicable to just one or more specific system-defined core scalar data type.
This documentation is pending.
These procedures are applicable to use in all kinds of procedures.
sys.Core.Control.fail (RO: Cat.Exception $topic)sys.Core.Control.try_catch (UPD: Tuple $try_updating, Tuple
$catch_updating ; RO: Cat.NameChain $try, Cat.NameChain $catch, Tuple
$try_assuming, Tuple $catch_assuming)$try argument, giving
it the arguments $try_updating and $try_assuming as its $updating
and $assuming arguments, respectively. If the $try procedure throws
an exception, then any state changes it made roll back (but changes made
before that don't), and the call stack unwinds to the try_catch itself;
then the procedure named by $catch is invoked similarly to $try was,
with corresponding arguments, but with the extra read-only argument
$topic whose value is a Cat.Exception; if the $catch procedure
also throws an exception (such as to say its not handling the thrown one),
then that one is not caught and the call stack unwinding plus applicable
transaction rollback carries on to the caller of the try_catch. If the
$try procedure succeeds (doesn't throw an exception), then the $catch
procedure is not called.
Go to the Language::MuldisD manpage for the majority of distribution-internal references, and the Language::MuldisD::SeeAlso manpage for the majority of distribution-external references.
Darren Duncan (perl@DarrenDuncan.net)
This file is part of the formal specification of the Muldis D language.
Muldis D is Copyright © 2002-2007, Darren Duncan.
See the LICENSE AND COPYRIGHT of the Language::MuldisD manpage for details.
The ACKNOWLEDGEMENTS in the Language::MuldisD manpage apply to this file too.
|
Language::MuldisD::Core - Muldis D core data types and operators |