NAME

Muldis::D::Dialect::HDMD_Perl6_STD - How to format Perl 6 Hosted Data Muldis D

VERSION

This document is Muldis::D::Dialect::HDMD_Perl6_STD version 0.112.0.

PREFACE

This document is part of the Muldis D language specification, whose root document is Muldis::D; you should read that root document before you read this one, which provides subservient details.

DESCRIPTION

This document outlines the grammar of the Hosted Data Muldis D standard dialect named HDMD_Perl6_STD. The fully-qualified name of this Muldis D standard dialect is [ 'Muldis_D', 'http://muldis.com', '0.112.0', 'HDMD_Perl6_STD' ].

The HDMD_Perl6_STD dialect is defined to be hosted in Perl 6, and is composed of just|mainly core Perl 6 types. This dialect is optimized for Perl 6 specifically, and doesn't try to match the version for Perl 5; you *will* have to reformat any Perl Hosted Data Muldis D when migrating between Perl 5 and Perl 6, same as with your ordinary Perl code.

This dialect is designed to exactly match the structure of a possible concrete syntax tree, comprised of native Perl 6 scalar and collection typed values, resulting from parsing code written in the Muldis D dialect PTMD_STD using Perl 6. This dialect exists as a convenience to Perl 6 programmers that want to generate or introspect Muldis D code by saving them the difficulty and overhead of escaping and stitching plain text code; it is expected that a Muldis D implementation written in Perl 6 will natively accept input in both the PTMD_STD and HDMD_Perl6_STD dialects. Furthermore, the HDMD_Perl6_STD dialect provides additional Muldis D syntax options to Perl 6 programmers besides what PTMD_STD would canonically parse into, such as the direct use of some Perl 6-only features.

Note that most of the details that the 2 dialects have in common are described just in the PTMD_STD file, for both dialects; this current file will mainly focus on the differences; you should read the Muldis::D::Dialect::PTMD_STD file before the current one, so to provide a context for better understanding it.

GENERAL STRUCTURE

A HDMD_Perl6_STD Muldis D code file is actually a Perl 6 code file that defines particular multi-dimensional Perl data structures which resemble possible concrete syntax trees (CSTs) from parsing PTMD_STD Muldis D code. Each component of a CST is called a node or node element, and roughly corresponds to a capture by the PTMD_STD parser. A node is typically represened as a Perl Seq|Array, but could alternately be a Perl scalar or something else, and so HDMD_Perl6_STD Muldis D code is typically a tree of Perl structures, called node trees, with Perl Seq|Array as the central nodes and Perl scalars as the leaf nodes. Often HDMD_Perl6_STD code is embedded or constructed in one or more files of a larger Perl 5 program that does more than define this code, such as various non-database-related tasks. A node tree is just composed using basic Perl data types, and there are no Muldis D node-specific Perl classes or objects required for doing this.

Note that Perl undefined values are not allowed anywhere in a node in the general case; you must use only defined values instead. This documentation also assumes that only defined values are used, and that supplying a Perl undef will result in an error. The few exceptions to this rule are explicitly stated.

The grammar in this file is informal and consists just of written descriptions of how each kind of node must be composed and how to interpret such Perl data structures as Muldis D code. Every named grammar node is a Perl Seq|Array unless otherwise stated, and every grammar element is a Seq|Array element; the first node element is the Seq|Array element at index zero, and so on.

The root grammar node for the entire dialect is Muldis_D.

START

A Muldis_D node has 2 ordered elements where the first element is a language_name node and the second element is either a value node or a depot node.

See the pod sections in this file named "LANGUAGE NAME", "VALUE LITERALS AND SELECTORS", and "DEPOT SPECIFICATION", for more details about the aforementioned tokens/nodes.

When Muldis D is being compiled and invoked piecemeal, such as because the Muldis D implementing virtual machine (VM) is attached to an interactive user terminal, or the VM is embedded in a host language where code in the host language invokes Muldis D code at various times, many value may be fed to the VM directly for inter-language exchange, and not every one would then have its own language_name. Usually a language_name would be supplied to the Muldis D VM just once as a VM configuration step, which provides a context for further interaction with the VM that just involves Muldis D code that isn't itself qualified with a language_name.

LANGUAGE NAME

As per the VERSIONING pod section of Muldis::D, code written in Muldis D must start by declaring the fully-qualified Muldis D language name it is written in. The HDMD_Perl6_STD dialect formats this name as a language_name node having 5 ordered elements:

ln_base_name

This is the Muldis D language base name; it is simply the Perl Str value Muldis_D.

ln_base_authority

This is the base authority; it is a Perl Str formatted as per a specific-context Name value literal, except that must be nonempty and it is expressly limited to using non-control characters in the ASCII repertoire; it is typically the Perl Str value http://muldis.com.

ln_base_version_number

This is the base version number; it is a Perl Str formatted as per ln_base_authority; it is typically a Perl Str value like 0.112.0.

ln_dialect

This is the dialect name; it is simply the Perl Str value HDMD_Perl6_STD.

ln_extensions

This is a set of chosen pragma/parser-config options, which is formatted similarly to a Tuple SCVL. The only 2 mandatory pragmas are catalog_abstraction_level (see the "CATALOG ABSTRACTION LEVELS" pod section) and op_char_repertoire (see "OPERATOR CHARACTER REPERTOIRE"). The only optional pragma is standard_syntax_extensions (see the "STANDARD SYNTAX EXTENSIONS" pod section). Other pragmas may be added later, which would likely be optional.

The value associated with the ln_extensions attribute named catalog_abstraction_level must be one of these 4 Perl Str values: the_floor, code_as_data, plain_rtn_inv, rtn_inv_alt_syn.

The value associated with the ln_extensions attribute named op_char_repertoire must be one of these 2 Perl character strings: basic, extended.

The value associated with the ln_extensions attribute named standard_syntax_extensions must be formatted similarly to a Set SCVL; each of the value's elements must be one of these 1 Perl Str values: temporal.

Examples:

[ 'Muldis_D', 'http://muldis.com', '0.112.0', 'HDMD_Perl6_STD', {
    catalog_abstraction_level => 'rtn_inv_alt_syn',
    op_char_repertoire => 'extended'
} ]

[ 'Muldis_D', 'http://muldis.com', '0.112.0', 'HDMD_Perl6_STD', {
    catalog_abstraction_level => 'rtn_inv_alt_syn',
    op_char_repertoire => 'extended',
    standard_syntax_extensions => Set.new('temporal')
} ]

CATALOG ABSTRACTION LEVELS

The catalog_abstraction_level pragma determines with a broad granularity how large the effective Muldis D grammar is that a programmer may employ with their Muldis D code.

The catalog abstraction level of some Muldis D code is a measure of how much or how little that code would resemble the system catalog data that the code would parse into. The lower the abstraction level, the smaller and simpler the used Muldis D grammar is and the more like data structure literals it is; the higher the abstraction level, the larger and more complicated the Muldis D grammar is and the more like general-purpose-language typical code it is.

There are currently 4 specified catalog abstraction levels, which when arranged from lowest to highest amount of abstraction, are: the_floor, code_as_data, plain_rtn_inv, rtn_inv_alt_syn. Every abstraction level has a proper superset of the grammar of every other abstraction level that is lower than itself, so for example any code that is valid code_as_data is also valid plain_rtn_inv, and so on.

the_floor

This abstraction level exists more as an academic exercise and is not intended to actually be used.

Examples:

[
    [ 'Muldis_D', 'http://muldis.com', '0.112.0', 'HDMD_Perl6_STD', {
        catalog_abstraction_level => 'the_floor',
        op_char_repertoire => 'basic'
    } ],
    :Relation( Set.new(
        {
            food => [ 'Scalar', 'Text', nfd_codes => {
                '' => :Relation( <index value> => Set.new(
                  [0,67],[1,97],[2,114],[3,114],[4,111],[5,116],[6,115]
                ) )
            } ],
            qty => 100
        },
        {
            food => [ 'Scalar', 'Text', nfd_codes => {
                '' => :Relation( <index value> => Set.new(
                    [0,75],[1,105],[2,119],[3,105],[4,115]
                ) )
            } ],
            qty => 30
        }
    ) )
]

code_as_data

This abstraction level is the best one for when you want to write code in exactly the same form as it would take in the system catalog.

Code written to the code_as_data level can employ all of the language grammar constructs described in these main pod sections: "VALUE LITERALS AND SELECTORS", "OPAQUE VALUE LITERALS", "COLLECTION VALUE SELECTORS".

Examples:

[
    [ 'Muldis_D', 'http://muldis.com', '0.112.0', 'HDMD_Perl6_STD', {
        catalog_abstraction_level => 'code_as_data',
        op_char_repertoire => 'basic'
    } ],
    :Relation( Set.new(
        { food => 'Carrots', qty => 100 },
        { food => 'Kiwis', qty => 30 }
    ) )
]

[
   [ 'Muldis_D', 'http://muldis.com', '0.112.0', 'HDMD_Perl6_STD', {
      catalog_abstraction_level => 'code_as_data',
      op_char_repertoire => 'basic'
   } ],
   [ 'depot', :depot-catalog[ 'Database', 'Depot', {
      functions => :Relation( Set.new(
         {
            name => :Name<cube>,
            material => [ 'Tuple', 'Function', {
               result_type => :PNSQNameChain<Int>,
               params => [ 'Relation', 'NameTypeMap', Set.new(
                  { name => :Name<topic>, type => :PNSQNameChain<Int> }
               ) ],
               expr => [ 'Database', 'ExprNodeSet', {
                  sca_val_exprs => :Relation( Set.new(
                     { name => :Name<INT_3>, value => 3 }
                  ) ),
                  func_invo_exprs => :Relation( Set.new(
                     {
                        name => :Name(''),
                        function => :PNSQNameChain<Integer.power>,
                        args => [ 'Relation', 'NameExprMap', [
                           {name=>:Name<radix>, expr=>:Name<topic>},
                           {name=>:Name<exponent>, expr=>:Name<INT_3>}
                        ] ]
                     }
                  ) )
               } ]
            } ]
         }
      ) )
   } ] ]
]

plain_rtn_inv

This abstraction level is the lowest one that can be recommended for general use.

Code written to the plain_rtn_inv level can employ all of the language grammar constructs that code_as_data can, plus all of those described in these main pod sections: "GENERIC VALUE EXPRESSIONS".

Examples:

[
    [ 'Muldis_D', 'http://muldis.com', '0.112.0', 'HDMD_Perl6_STD', {
        catalog_abstraction_level => 'plain_rtn_inv',
        op_char_repertoire => 'basic'
    } ],
    [ 'depot', :depot-catalog[
        [ 'function', 'cube', [ 'Int', { topic => 'Int' }, [
            [ 'func-invo', 'Integer.power',
                { radix => ['$','topic'], exponent => 3 } ]
        ] ] ]
    ] ]
]

rtn_inv_alt_syn

This abstraction level is the highest one and is the most recommended one for general use.

Code written to the rtn_inv_alt_syn level can employ all of the language grammar constructs that plain_rtn_inv can, plus all of those described in these main pod sections: "FUNCTION INVOCATION ALTERNATE SYNTAX EXPRESSIONS".

Examples:

[
    [ 'Muldis_D', 'http://muldis.com', '0.112.0', 'HDMD_Perl6_STD', {
        catalog_abstraction_level => 'rtn_inv_alt_syn',
        op_char_repertoire => 'basic'
    } ],
    [ 'depot', :depot-catalog[
        [ 'function', 'cube', [ 'Int', { topic => 'Int' }, [
            [ 'op', 'I^', [ ['$','topic'], 3 ] ]
        ] ] ]
    ] ]
]

OPERATOR CHARACTER REPERTOIRE

The op_char_repertoire pragma determines primarily whether or not the various routine invocation alternate syntaxes, herein called operators, may be composed of only ASCII characters or also other Unicode characters, and this pragma determines secondarily whether or not a few special value literals (effectively nullary operators) composed of non-ASCII Unicode characters may exist.

There are currently 2 specified operator character repertoires: basic, extended. The latter is a proper superset of the former.

Specifying the op_char_repertoire pragma in a language_name node is mandatory, since there is no obviously best setting to use implicitly when one isn't specified.

basic

The basic operator character repertoire is the smallest one, and it only supports writing the proper subset of defined operator invocations and special value literals that are composed of just 7-bit ASCII characters. This repertoire can be recommended for general use, especially since code written to it should be the most universally portable as-is (with respect to operator character repertoires), including full support even by minimal Muldis D implementations and older text editors.

extended

The extended operator character repertoire is the largest one, and it supports the entire set of defined operator invocations and special value literals, many of which are composed of Unicode characters outside the 7-bit ASCII repertoire. This is the most recommended repertoire for general use, assuming that all the Muldis D implementations and source code text editors you want to use support it.

STANDARD SYNTAX EXTENSIONS

The standard_syntax_extensions pragma declares which optional portions of the Muldis D grammar a programmer may employ with their Muldis D code.

There is currently 1 specified standard syntax extension: temporal. These are all mutually independent and any or all may be used at once.

While each standard syntax extension is closely related to a Muldis D language extension, you can use the latter's types and routines without declaring the former; you only declare you are using a standard syntax extension if you want the Muldis D parser to recognize special syntax specific to those types and routines, and otherwise you just use them using the generic syntax provided for all types and routines.

The standard_syntax_extensions pragma is generally orthogonal to the catalog_abstraction_level pragma, so you can combine any value of the latter with any value-list of the former. However, in practice all standard syntax extensions will have no effect when the catalog abstraction level is the_floor, and some of their features may only take effect when the catalog abstraction level is rtn_inv_alt_syn, as is appropriate.

Specifying the standard_syntax_extensions pragma in a language_name node is optional, and when omitted it defaults to the empty set, meaning no extensions may be used.

temporal

The temporal standard syntax extension is closely related to the Muldis::D::Ext::Temporal language extension, and it constitutes special syntax for its data types; in the future it may improve the type syntax or add syntax for operators.

VALUE LITERALS AND SELECTORS

A value node is a Muldis D value literal, which is a common special case of a Muldis D value selector.

There are 22 main varieties of value node, each of which is a named node kind of its own: Bool, Order, RatRoundMeth, Int, Rat, Blob, Text, Name, NameChain, PNSQNameChain, Comment, RatRoundRule, Scalar, Tuple, Database, Relation, Set, Maybe, Array, Bag, [S|M]PInterval.

Fundamentally, the various Muldis D scalar and collection types are represented by their equivalent Perl native scalar and collection types. But since Muldis D is more strongly typed, or at least differently typed, than Perl, each value node is represented by a Perl Seq|Array, whose elements include both the payload Perl literal plus explicit meta-data for how to interpret that Perl literal for mapping to Muldis D.

Value Literal Common Elements

Every value node is either a GCVL (generic context value literal) or a SCVL (specific context value literal).

Every GCVL has 1-3 ordered elements:

value_kind

This is a Perl Str value of the format <[A..Z]> <[ a..z A..Z ]>+; it identifies the data type of the value literal in broad terms and is the only external meta-data of value_payload generally necessary to interpret the latter; what grammars are valid for value_payload depend just on value_kind.

For just some data types, the value_kind may be omitted; see below.

type_name

Only when the value node has 3 elements: This is a Muldis D data type name, for example sys.std.Core.Type.Int; it identifies a specific subtype of the generic type denoted by value_kind, and serves as an assertion that the Muldis D value denoted by value_payload is a member of the named subtype. Its format is a PNSQNameChain_payload node. Iff value_kind is [|DH]Scalar then type_name is mandatory; otherwise, type_name is optional for all value, except that type_name must be omitted when value_kind is one of the 2 [Bool, Order]; this isn't because those 2 types can't be subtyped, but because in practice doing so isn't useful.

value_payload

This is mandatory for all value. Format varies with value_kind.

A Perl Pair may alternately be used to represent a GCVL iff that node has exactly 2 elements (value_kind and value_payload); in that case, the value_kind is stored in that Pair's key, and the value_payload is stored in the Pair's value.

For some data types, a GCVL may alternately be just its payload for the sake of brevity. If any Perl value of one of the following types is encountered where a GCVL node is expected, then it is interpreted as a full value node as follows:

Muldis D   <- Perl 6
----------------------------
Bool       <- Bool
Order      <- Order
Int        <- Int
Rat        <- FatRat|Rat|Num
Blob       <- Blob
Text       <- Str
SPInterval <- Range
TAIInstant <- Instant
TAIDuration <- Duration

The above details are subject to revision regarding when a Perl object might claim to do multiple type interfaces.

For GCVL and SCVL examples, see the subsequent documentation sections.

OPAQUE VALUE LITERALS

Boolean Literals

A Bool node represents a logical boolean value. It is interpreted as a Muldis D sys.std.Core.Type.Bool value as follows: The payload must be a Perl Bool, and so Bool::False and Bool::True are mapped directly.

Examples:

:Bool(Bool::True)

Bool::False

Order-Determination Literals

An Order node represents an order-determination. It is interpreted as a Muldis D sys.std.Core.Type.Cat.Order value as follows: The payload must be a Perl Order, and so Order::Increase and Order::Same and Order::Decrease are mapped directly.

Examples:

:Order(Order::Same)

Order::Decrease

Rational Rounding Method Literals

A RatRoundMeth node represents a rational rounding method. It is interpreted as a Muldis D sys.std.Core.Type.Cat.RatRoundMeth value by directly mapping the payload. The payload must be a Perl Str having one of the 7 values HalfDown, HalfUp, HalfEven, ToFloor, ToCeiling, ToZero, ToInf.

Examples:

:RatRoundMeth<HalfUp>

:RatRoundMeth<ToZero>

General Purpose Integer Numeric Literals

An Int node represents an integer numeric value. It is interpreted as a Muldis D sys.std.Core.Type.Int value as follows: The payload must be a Perl Int, which is mapped directly.

Examples:

:Int(:2<11001001>) # binary #

:8<0> # octal #

:8<644> # octal #

-34 # decimal #

42 # decimal #

:16<DEADBEEF> # hexadecimal #

:36<-HELLOWORLD> # base-36 #

:4<301> # base-4 #

:12<A09B> # base-12 #

General Purpose Rational Numeric Literals

A Rat node represents a rational numeric value. It is interpreted as a Muldis D sys.std.Core.Type.Rat value as follows: The payload must be a Perl FatRat|Rat|Num|Int, which is mapped directly.

Examples:

:Rat(:2<-1.1>)

-1.5 # same val as prev #

3.14159

:11<0.0>

:16<DEADBEEF.FACE>

:36<0.000AZE>

:Rat(:7<500001>/:7<1000>)

:12<A09B>/:12<A>

:Rat(:2<1011101101> * :2<10> ** :2<-11011>)

45207196 * 10 ** 37

1/43

314159 * 10 ** -5

General Purpose Binary String Literals

A Blob node represents a general purpose bit string. It is interpreted as a Muldis D sys.std.Core.Type.Blob value as follows: The payload must be a Perl Blob, which is mapped directly.

Examples TODO: What is the actual syntax for the P6 Blob type?:

:Blob( Blob.new(  2 => '00101110100010' ) ) # binary #

 Blob.new(  4 => '' )

 Blob.new( 16 => 'A705E' ) # hexadecimal #

 Blob.new(  8 => '523504376' )

General Purpose Character String Literals

A Text node represents a general purpose character string. It is interpreted as a Muldis D sys.std.Core.Type.Text value by directly mapping the payload. The payload must be a Perl Str.

Examples:

:Text<Ceres>

'サンプル'

''

'Perl'

"\c[LATIN SMALL LETTER OU]\x[263A]\c[65]"

DBMS Entity Name Literals

A Name node represents a canonical short name for any kind of DBMS entity when declaring it; it is a character string type, that is disjoint from Text. It is interpreted as a Muldis D sys.std.Core.Type.Cat.Name value by directly mapping the payload. The payload must be a Perl Str.

A NameChain node represents a canonical long name for invoking a DBMS entity in some contexts; it is conceptually a sequence of entity short names. Its payload is a Perl Seq|Array value or Str value. This node is interpreted as a Muldis D sys.std.Core.Type.Cat.NameChain value as follows:

If the payload is a Seq|Array, then every element must be a valid payload for a Name node (that is, any Perl character string). Each element of the payload, in order, defines an element of the array possrep's attribute of a NameChain.
If the payload is a Str, then it must be formatted as a catenation (using period (.) separators) of at least 1 part, where each part can not have any literal period (.) characters (if you want literal periods then you can only use the Seq|Array payload format to express it). The Str format of payload is interpreted by splitting it on the separators into the Seq|Array format, then processed as per the latter. A zero part chain can only be expressed with the Seq|Array payload format; an empty string Str format will be interpreted as having a single element that is the empty string.

Fundamentally a PNSQNameChain node is exactly the same as a NameChain node in format and interpretation, with the primary difference being that it may only define NameChain values that are also values of the proper subtype sys.std.Core.Type.Cat.PNSQNameChain, all of which are nonempty chains. Now that distinction alone wouldn't be enough rationale to have these 2 distinct node kinds, and so the secondary difference between the 2 provides that rationale; the PNSQNameChain node supports a number of chain value shorthands while the NameChain node supports none.

A PNSQNameChain node is interpreted the same as a NameChain node except for the extra restrictions and shorthands. If the first element of a PNSQNameChain payload is the empty string then the payload is treated as if the first element were instead topic.

Examples:

:Name<login_pass>

:Name('First Name')

:NameChain['gene','sorted_person_name']

:NameChain('stats.samples by order')

:NameChain[]

:PNSQNameChain['fed','data','the_db','gene','sorted_person_names']

:PNSQNameChain('fed.data.the_db.stats.samples by order')

:PNSQNameChain<.attr>  # same as :PNSQNameChain<lex.topic.attr> #

Code Comment Literals

A Comment node represents the text of a Muldis D code comment; it is a character string type, that is disjoint from both Text and Name. It is interpreted as a Muldis D sys.std.Core.Type.Cat.Comment value by directly mapping the payload. The payload must be a Perl Str.

Examples:

:Comment('This does something.')

:Comment('So does this.')

Rational Rounding Rule Literals

A RatRoundRule node represents a rational rounding rule. It is interpreted as a Muldis D sys.std.Core.Type.Cat.RatRoundRule value whose attributes are defined by the RatRoundRule_payload. A RatRoundRule_payload must be a Perl Seq|Array with 3 elements, which correspond in order to the 3 attributes: radix (a PInt2_N), min_exp (an Int), and round_meth (a RatRoundMeth). Each of radix and min_exp must qualify as a valid Int_payload, and round_meth must qualify as a valid RatRoundMeth_payload.

Examples:

:RatRoundRule[10,-2,'HalfEven']

:RatRoundRule[2,-7,'ToZero']

COLLECTION VALUE SELECTORS

Note that, with each of the main value selector nodes documented in this main POD section, any occurrences of child expr nodes should be read as being value nodes instead in contexts where instances of the main nodes are being composed beneath value nodes. That is, any expr node options beyond what value options exist are only valid within a depot node.

Scalar Selectors

A Scalar node represents a literal or selector invocation for a not-Int scalar subtype value. It is interpreted as a Muldis D sys.std.Core.Type.Scalar subtype value whose declared type is specified by the node's (mandatory for Scalar) type_name element and whose attributes are defined by the payload. If the payload is a Perl Pair, then its key and value, respectively, are designated possrep name and possrep attrs; if the payload is not a Perl Pair, then it is interpreted as if it was just the possrep attrs, and the possrep name was the empty string. The possrep name and possrep attrs must be as per the payload of a Name and Tuple node, respectively. The possrep attrs is interpreted specifically as attributes of the declared type's possrep which is specified by the possrep name. Each key+value pair of the possrep attrs defines a named possrep attribute of the new scalar; the pair's key and value are, respectively, a Perl Str that specifies the possrep attribute name, and an expr node that specifies the possrep attribute value.

Examples:

[ 'Scalar', 'sys.std.Core.Type.Cat.Name', { '' => 'the_thing' } ]

[ 'Scalar', 'sys.std.Core.Type.Rat', float => {
    mantissa => 45207196,
    radix    => 10,
    exponent => 37,
} ]

[ 'Scalar', 'sys.std.Temporal.Type.UTCDateTime', datetime => {
    year   => 2003,
    month  => 10,
    day    => 26,
    hour   => 1,
    minute => 30,
    second => 0.0,
} ]

[ 'Scalar', 'fed.lib.the_db.WeekDay', name => {
    '' => 'monday',
} ]

[ 'Scalar', 'fed.lib.the_db.WeekDay', number => {
    '' => 5,
} ]

[ 'Scalar', 'Text', nfd_codes => {
    '' => :Array[80,101,114,109]
} ]  # 'Perl' #

Tuple Selectors

A Tuple node represents a literal or selector invocation for a tuple value. It is interpreted as a Muldis D sys.std.Core.Type.Tuple value whose attributes are defined by the payload. The payload must be a Perl Mapping|Hash. Each key+value pair of the payload defines a named attribute of the new tuple; the pair's key and value are, respectively, a Perl Str that specifies the attribute name, and an expr node that specifies the attribute value.

Examples:

:Tuple{}

[ 'Tuple', 'type.tuple_from.var.fed.data.the_db.account.users', {
    login_name => 'hartmark',
    login_pass => 'letmein',
    is_special => Bool::True,
} ]

:Tuple{
    name => 'Michelle',
    age  => 17,
}

Database Selectors

A Database node represents a literal or selector invocation for a 'database' value. It is interpreted as a Muldis D sys.std.Core.Type.Database value whose attributes are defined by the payload. The payload must be a Perl Mapping|Hash. Each key+value pair of the payload defines a named attribute of the new 'database'; the pair's key and value are, respectively, a Perl Str that specifies the attribute name, and an expr node that specifies the attribute value, which must be represent a relation value.

Relation Selectors

A Relation node represents a literal or selector invocation for a relation value. It is interpreted as a Muldis D sys.std.Core.Type.Relation value whose attributes and tuples are defined by the payload, which is interpreted as follows:

Iff the payload is a Perl Set|KeySet with zero elements, then it defines the only relation value having zero attributes and zero tuples.
Iff the payload is a Perl Set|KeySet with at least one element, and every element is a Perl Str (as per a valid payload for a Name node), then it defines the attribute names of a relation having zero tuples.
Iff the payload is a Perl Set|KeySet with at least one element, and every element is a Perl Mapping|Hash (as per a valid payload for a Tuple node), then each element of the payload defines a tuple of the new relation; every tuple-defining element of the payload must be of the same degree and have the same attribute names as its sibling elements; these are the degree and attribute names of the relation as a whole, which is its heading for the current purposes.
Iff the payload is a Perl Pair, then: The new relation value's attribute names are defined by the payload's key, which is a Perl Seq|Array of Str (each as per a Name node payload), and the relation body's tuples' attribute values are defined by the payload's value, which is a Perl Set|KeySet of Seq|Array of tuple attribute value defining nodes. This format is meant to be the most compact of the generic relation payload formats, as the attribute names only appear once for the relation rather than repeating for each tuple. As a trade-off, the attribute values per tuple from the payload value must appear in the same order as their corresponding attribute names appear in the payload key, as the names and values in the relation literal are matched up by ordinal position here.

Examples TODO: What is the actual syntax for the P6 Set type?:

:Relation( Set.new() )  # zero attrs + zero tuples #

:Relation( Set.new(<x y z>) )  # 3 attrs + zero tuples #

:Relation( Set.new( {} ) )  # zero attrs + 1 tuple #

:Relation( Set.new(
    {
        login_name => 'hartmark',
        login_pass => 'letmein',
        is_special => Bool::True,
    },
) )  # 3 attrs + 1 tuple #

[ 'Relation', 'fed.lib.the_db.gene.Person', <name age> => Set.new(
    [ 'Michelle', 17 ],
) ]  # 2 attrs + 1 tuple #

Set Selectors

A Set node represents a literal or selector invocation for a set value. It is interpreted as a Muldis D sys.std.Core.Type.Set value whose elements are defined by the payload. The payload must be a Perl Set|KeySet. Each element of the payload defines a unary tuple of the new set; each element is an expr node that defines the value attribute of the tuple.

Examples TODO: What is the actual syntax for the P6 Set type?:

[ 'Set', 'fed.lib.the_db.account.Country_Names', Set.new(
    'Canada',
    'Spain',
    'Jordan',
    'Thailand',
) ]

:Set( Set.new(
    3,
    16,
    85,
) )

Maybe Selectors

A Maybe node represents a literal or selector invocation for a maybe value. It is interpreted as a Muldis D sys.std.Core.Type.Maybe value. If the node payload is missing or undefined, then the node is interpreted as the special value Maybe:Nothing, aka Nothing, which is the only Maybe value with zero elements. If the node payload is defined then the node is interpreted as a Single whose element is defined by the payload. The payload is an expr node that defines the value attribute of the single tuple of the new 'single'.

Examples:

:Maybe( 'I know this one!' )

:Maybe()  # or how does Perl 6 make a Pair with undef/default value? #

Array Selectors

An Array node represents a literal or selector invocation for a array value. It is interpreted as a Muldis D sys.std.Core.Type.Array value whose elements are defined by the payload. The payload must be a Perl Seq|Array. Each element of the payload defines a binary tuple of the new sequence; the element value is an expr node that defines the value attribute of the tuple, and the element index is used as the index attribute of the tuple.

Examples:

:Array[
    'Alphonse',
    'Edward',
    'Winry',
]

[ 'Array', 'fed.lib.the_db.stats.Samples_By_Order', [
    57,
    45,
    63,
    61,
] ]

Bag Selectors

A Bag node represents a literal or selector invocation for a bag value. It is interpreted as a Muldis D sys.std.Core.Type.Bag value whose elements are defined by the payload. The payload must be a Perl Bag|KeyBag|Set|KeySet value; the payload element keys are expr nodes corresponding to the value attribute of the new bag's tuples, and the payload element values are positive integers (or Bool::True, which counts as the number 1) corresponding to the count attribute; the payload element mapping is as you should expect.

Examples TODO: What is the actual syntax for the P6 Bag type?:

[ 'Bag', 'fed.lib.the_db.inventory.Fruit', Bag.new(
    'Apple'  => 500,
    'Orange' => 300,
    'Banana' => 400,
) ]

:Bag( Bag.new( [
    'Foo',
    'Quux',
    'Foo',
    'Bar',
    'Baz',
    'Baz',
] ) )

Interval Selectors

An SPInterval node represents a literal or selector invocation for a single-piece interval value. It is interpreted as a Muldis D sys.std.Core.Type.SPInterval value whose attributes are defined by the payload. The node payload must be a Perl Range, which is mapped directly. Each of the min and max attributes/method-return-values of the Range is an expr node that defines the min and max attribute value, respectively, of the new single-piece interval. Each of the excludes_min and excludes_max of the Range maps directly with the single-piece interval.

A special shorthand for an SPInterval payload also exists, which is to help with the possibly common situation where an interval is a singleton, meaning the interval has exactly 1 value; the shorthand empowers that value to be specified just once rather than twice. Iff the payload is not a Perl Range, then the payload is treated as if it was instead the usual Perl Range, whose min and max are both identical to the actual payload and whose excludes_min and excludes_max are both Bool::False. For example, the payload 6 is shorthand for 6..6.

An MPInterval node represents a literal or selector invocation for a multi-piece interval value. It is interpreted as a Muldis D sys.std.Core.Type.MPInterval value whose elements are defined by the payload. The payload must be a Perl Set|KeySet. Each element of the payload must be a valid payload for an SPInterval node (that is, a Perl Range). Each element of the payload defines a 4-ary tuple, representing a single-piece interval, of the new multi-piece interval.

Examples TODO: What is the actual syntax for the P6 Set type?:

:SPInterval(1..10)

2.7..^9.3

'a'^..'z'

:UTCInstant[2002,12,6] ^..^ :UTCInstant[2002,12,20]

:SPInterval<abc>  # 1 element #

:MPInterval( Set.new() )  # zero elements #

:MPInterval( Set.new(1..10) )  # 10 elements #

:MPInterval( Set.new(1..3,6,8..9) )  # 6 elements #

DEPOT SPECIFICATION

A depot node has 2-3 ordered elements such that 3 elements means the depot has a normal-user-data database and 2 elements means it has just a (possibly empty) system catalog database: The first element is the Perl Str value depot. Iff the depot has 3 elements then the third element specifies the normal-user-data database; it is a Perl Pair whose key is the Perl Str value depot-data and whose value is a Database node. The second element specifies the system catalog database; it is a Perl Pair whose key is the Perl Str value depot-catalog and whose value is either a Database node or a Perl Seq|Array which is hereafter referred to as depot_catalog_payload. A depot_catalog_payload either has zero elements, designating an empty catalog, or all of its elements are Perl Seq|Array (in particular, none of its elements is the Perl Str value 'Database'), each of which is one of the following kinds of nodes: subdepot, material, self_local_dbvar_type.

A subdepot node has 3 ordered elements: The first element is the Perl Str value subdepot. The second element is a Name_payload, which is the declared name of the subdepot within the namespace defined by its parent subdepot (or depot). The third element is a depot_catalog_payload.

A self_local_dbvar_type node has 2 ordered elements: The first element is the Perl Str value self-local-dbvar-type. The second element is a PNSQNameChain_payload, which specifies what the normal-user-data database has as its declared data type.

Examples:

# A completely empty depot that doesn't have a self-local dbvar. #
[ 'depot', :depot-catalog[] ]

# Empty depot with self-local dbvar with unrestricted allowed values. #
[ 'depot',
    :depot-catalog[
        [ 'self-local-dbvar-type', 'Database' ]
    ],
    :depot-data[ 'Database', {} ]
]

# A depot having just one function and no dbvar. #
[ 'depot', :depot-catalog[
    [ 'function', 'cube', [ 'Int', { topic => 'Int' }, [
        [ 'op', 'I^', [ ['$','topic'], 3 ] ]
    ] ] ]
] ]

MATERIAL SPECIFICATION

A material node specifies a new material (routine or type) that lives in a depot or subdepot.

There are 9 main varieties of material node, each of which is a named node kind of its own: function, updater, procedure, scalar_type, tuple_type, relation_type, domain_type, subset_type, mixin_type.

Material Specification Common Elements

A material node has 2-3 ordered elements, such that a material that has 2 elements is an anon_material and a material with 3 elements is a named_material: The first element is material_kind. The last element is material_payload. Iff there are 3 elements then the middle element is material_declared_name.

material_kind: This is a Perl Str value of the format [<[ a..z ]>+] ** '-'; it identifies the kind of the material and is the only external meta-data of material_payload generally necessary to interpret the latter; what grammars are valid for material_payload depend just on material_kind.
material_declared_name: This is the declared name of the material within the namespace defined by its subdepot (or depot). It is explicitly specified iff the material is a named_material
material_payload: This is mandatory for all material. It specifies the entire material sans its name. Format varies with material_kind.

For material examples, see the subsequent documentation sections.

Function Specification

TODO.

Updater Specification

TODO.

Procedure Specification

TODO.

Scalar Type Specification

TODO.

Tuple Type Specification

TODO.

Relation Type Specification

TODO.

Domain Type Specification

TODO.

Subset Type Specification

TODO.

Mixin Type Specification

TODO.

GENERIC VALUE EXPRESSIONS

An expr_name node has 2 ordered elements: The first element is the Perl Str value $. The second element is a Name_payload.

An expr_name node may alternately be formatted as a Perl Pair whose key and value are what would otherwise be the first and second node elements, respectively.

A named_expr node has 3 ordered elements: The first element is the Perl Str value ::=. The second element is a Name_payload and the third element is an expr node; the second element declares an explicit expression node name for the third element.

Examples:

# an expr_name node #
['$','foo_expr']

# a named_expr node #
[ '::=', 'bar_expr', [ 'func-invo', 'factorial', [['$','foo_expr']] ] ]

Generic Expression Attribute Accessors

An accessor node has 2-3 ordered elements, such that 2 elements makes it an acc_via_named and 3 elements makes it an acc_via_anon: The first element is the Perl Str value $.. The last element of an acc_via_named is a PNSQNameChain_payload, which is by itself the target of the accessor (naming both the other node plus its attribute to alias). The second element of an acc_via_anon is an expr node which is the other node whose attribute is being aliased. The last element of an acc_via_anon is a nonempty NameChain_payload and names the attribute.

Examples:

# an accessor node of a named tuple-valued node #
['$.','foo_t.bar_attr']

# an accessor node of an anonymous tuple-valued node #
['$.',['func-invo','nlx.lib.tuple_res_func',[['$','arg']]],'quux_attr']

Generic Function Invocation Expressions

A func_invo node has 2-4 ordered elements: The first element is the Perl Str value func-invo. The second element is a PNSQNameChain_payload, which names the function to invoke. The last 1-2 elements provide arguments to the function invocation; either or both or none of an Array_payload element and a Tuple_payload element may be given. The Array_payload 3rd/4th element is for any anonymous (and ordered if multiple exist) arguments, and the Tuple_payload 3rd/4th element is for any named arguments; each Array_payload element or Tuple_payload element value is an expr node which is the argument value.

Examples:

# zero params #
[ 'func-invo', 'Nothing' ]

# single mandatory param #
[ 'func-invo', 'Integer.median',
    [ :Bag( Bag.new( [ 22, 20, 21, 20, 21, 21, 23 ] ) ) ] ]

# single mandatory param #
[ 'func-invo', 'factorial', { topic => 5 } ]

# two mandatory params #
[ 'func-invo', 'Rational.quotient',
    { dividend => 43.7, divisor => 16.9 } ]

# one mandatory 'topic' param, two optional #
[ 'func-invo', 'nlx.lib.barfunc', [ ['$','mand_arg'] ],
    { oa1 => ['$','opt_arg1'], oa2 => ['$','opt_arg2'] } ]

# a user-defined function #
[ 'func-invo', 'nlx.lib.foodb.bazfunc',
    { a1 => 52, a2 => 'hello world' } ]

# two params named 'topic' and 'other' #
[ 'func-invo', 'is_identical', [ ['$','foo'], ['$','bar'] ] ]

# invoke the lexically innermost routine with 2 args #
[ 'func-invo', 'rtn', [ ['$','x'], ['$','y'] ] ]

Generic If-Else Expressions

An if_else_expr node has 2-3 ordered elements: The first element is either of the 2 Perl Str values if-else-expr and ??!!. The optional second element is if_then, a Perl Seq|Array with 0..N elements, each of those being a 2-element Perl Seq|Array or a Perl Pair, where each element is an expr node; the first element / key is an if condition expression, and the second element / value is the associated then result expression. The 3rd/last element of an if_else_expr node is else result expression, which is an expr node.

Examples:

[ 'if-else-expr',
    [
        [ 'op', '>', [['$','foo'], 5] ] => ['$','bar'],
    ],
    ['$','baz']
]

[ 'if-else-expr',
    [
        [ 'op', 'is-empty', [['$','ary']] ] => ['$','empty_result'],
    ],
    [ 'op', '.[]', [['$','ary'], 0] ]
]

[ 'op', 'T~', ['My answer is: ',
    [ '??!!', [ ['$','maybe'] => 'yes' ], 'no' ]] ]

Generic Given-When-Default Expressions

A given_when_def_expr node has 3-4 ordered elements: The first element is the Perl Str value given-when-def-expr. The second element is an expr node which is the given common comparand. The optional third element is when_then, a Perl Seq|Array with 0..N elements, each of those being a 2-element Perl Seq|Array or a Perl Pair, where each element is an expr node; the first element / key is a when comparand, and the second element / value is the associated then result expression. The 4th/last element of a given_when_def_expr node is default result expression, which is an expr node.

Examples:

[ 'given-when-def-expr',
    ['$','digit'],
    [
        'T' => 10,
        'E' => 11,
    ],
    ['$','digit'],
]

Library Entity Reference Selector

TODO: REWRITE THIS DOCUMENTATION SECTION!

A [func|proc|type|ord-det-func]-ref node may alternately be formatted as a Perl Pair whose key and value are what would otherwise be the first and second node elements, respectively.

Examples:

:func-ref<nlx.lib.filter>

:upd-ref<nlx.lib.swap>

:proc-ref<nlx.lib.try_block>

:type-ref<nlx.lib.foo_type>

:ord-det-func-ref<nlx.lib.order_bars>

FUNCTION INVOCATION ALTERNATE SYNTAX EXPRESSIONS

A func_invo_alt_syntax node has 3-4 ordered elements: The first element is the Perl Str value op. The second element is a Perl Str value, hereafter referred to as op or keyword, which determines the function to invoke. The third element is (usually) a Perl Seq|Array, hereafter referred to as main op args, which is an ordered list of 1-N mandatory inputs to the function invocation. The (optional) fourth element is a Perl Mapping|Hash, hereafter referred to as extra op args, which is a named list of optional function inputs. The number and format of elements of either main op args or extra op args varies depending on op. Note that, when a main op args would just contain a single element, such as when it is for a monadic operator, it may alternately be formatted as what is otherwise just its sole (node) element iff that node is not formatted as a Perl Seq|Array.

Simple Commutative N-adic Infix Reduction Operators

A comm_infix_reduce_op_invo node has 2-N main op args, each of which is an expr node. Note that the main op args may alternately be given as a Perl Bag|KeyBag|Set|KeySet rather than a Perl Seq|Array.

Examples:

[ 'op', 'and', [ Bool::True, Bool::False, Bool::True ] ]

[ 'op', 'or', [ Bool::True, Bool::False, Bool::True ] ]

[ 'op', 'xor', [ Bool::True, Bool::False, Bool::True ] ]

[ 'op', 'I+', [ 14, 3, -5 ] ]

[ 'op', 'I*', [ -6, 2, 25 ] ]

[ 'op', 'N+', [ 4.25, -0.002, 1.0 ] ]

[ 'op', 'N*', [ 69.3, 15 * 2 ** 6, 49/23 ] ]

[ 'op', '∪', [ :Set( Set.new( 1, 3, 5 ) ),
    :Set( Set.new( 4, 5, 6 ) ), :Set( Set.new( 0, 9 ) ) ] ]

[ 'op', '∩', [ :Set( Set.new( 1, 3, 5, 7, 9 ) ),
    :Set( Set.new( 3, 4, 5, 6, 7, 8 ) ), :Set( Set.new( 2, 5, 9 ) ) ] ]

Simple Non-commutative N-adic Infix Reduction Operators

A noncomm_infix_reduce_op_invo node has 2-N main op args, each of which is an expr node.

Examples:

[ 'op', '[<=>]', [ Order::Same, Order::Increase, Order::Decrease ] ]

[ 'op', 'B~', [ Blob.new( 16 => 'DEAD' ),
    Blob.new( 2 => '10001101' ), Blob.new( 16 => 'BEEF' ) ] ]

[ 'op', 'T~', [ 'hello', ' ', 'world' ] ]

[ 'op', 'A~', [ :Array[24, 52], :Array[-9], :Array[0, 11, 24, 7] ] ]

[ 'op', '//', [ ['$','a'], ['$','b'], 42 ] ]

[ 'op', '//d', [ ['$','a'], ['$','b'], :type-ref<nlx.lib.foo_type> ] ]

Simple Symmetric Dyadic Infix Operators

A sym_dyadic_infix_op_invo node has exactly 2 main op args, each of which is an expr node; which function arguments get which main op args isn't significant.

Examples:

[ 'op', '=', [ ['$','foo'], ['$','bar'] ] ]

[ 'op', '≠', [ ['$','foo'], ['$','bar'] ] ]

[ 'op', 'nand', [ Bool::False, Bool::True ] ]

[ 'op', 'I|-|', [ 15, 17 ] ]

[ 'op', 'N|-|', [ 7.5, 9.0 ] ]

Simple Non-symmetric Dyadic Infix Operators

A nonsym_dyadic_infix_op_invo node has exactly 2 main op args, each of which is an expr node; the first and second main op args are lhs and rhs, respectively.

Examples:

[ 'op', 'isa', [ ['$','bar'], :type-ref<nlx.lib.foo_type> ] ]

[ 'op', '!isa', [ ['$','bar'], :type-ref<nlx.lib.foo_type> ] ]

[ 'op', 'as', [ ['$','scalar'], :type-ref<Int> ] ]

[ 'op', 'asserting', [['$','int'], [ 'op', '≠', [['$','int'], 0] ]] ]

[ 'op', 'implies', [ Bool::True, Bool::False ] ]

[ 'op', 'I-', [ 34, 21 ] ]

[ 'op', 'I/', [ 5, 3 ] ]

[ 'op', '%', [ 5, 3 ] ]

[ 'op', 'I^', [ 2, 63 ] ]

[ 'op', 'N-', [ 9.2, 0.1 ] ]

[ 'op', 'N/', [ :2<101.01>, :2<11.0> ] ]

[ 'op', 'Tx', [ '-', 80 ] ]

[ 'op', '∖', [:Set(Set.new( 8, 4, 6, 7 )), :Set(Set.new( 9, 0, 7 ))] ]

[ 'op', '÷', [ :Relation( <x y> => Set.new( [ 5, 6 ], [ 3, 6 ] ) ),
    :Relation( Set.new( { y => 6 } ) ) ] ]

Simple Monadic Prefix Operators

A monadic_prefix_op_invo node has exactly 1 main op arg, which is an expr node.

Examples:

[ 'op', 'd', :type-ref<nlx.lib.foo_type> ]

[ 'op', 'not', Bool::True ]

[ 'op', 'I||', -23 ]

[ 'op', 'N||', -4.59 ]

[ 'op', 'R#', :Set(Set.new( 5, -1, 2 )) ]

[ 'op', 't', [['$','relvar']] ]

[ 'op', 'r', [['$','tupvar']] ]

[ 'op', 's', [[ 'op', 'N+',
    [[ 'op', 'v', ['$','a'] ], [ 'op', 'v', ['$','b'] ]] ]] ]

Simple Monadic Postfix Operators

A monadic_postfix_op_invo node has exactly 1 main op arg, which is an expr node.

Examples:

[ 'op', '++', 13 ]

[ 'op', '--', 4 ]

[ 'op', 'I!', 5 ]

Simple Postcircumfix Operators

A postcircumfix_op_invo node has exactly 2-3 main op args, where the first is an expr node that defines the primary input value for the operator and the other 1-2 provide attribute names that customize the operation.

Note that for the [] op, the min_index, interval_boundary_kind, max_index are collectively the 2nd main op arg which is an SPInterval node payload that defines an sp_interval_of.NNInt.

Examples:

[ 'op', '.${}', [['$','birthday'], 'date', 'day'] ]

[ 'op', '.%{}', [['$','pt'], 'city'] ]

[ 'op', '%{<-}', [['$','pt'], {pnum=>'pno', locale=>'city'}] ]

[ 'op', '@{<-}', [['$','pr'], {pnum=>'pno', locale=>'city'}] ]

[ 'op', '${}', [['$','birthday'], 'date', ['year','month']] ]

[ 'op', '%{}', [['$','pt'], ['color','city']] ]

[ 'op', '@{}', [['$','pr'], ['color','city']] ]

[ 'op', '%{}', [['$','pt'], []] ]  # null projection #

[ 'op', '@{}', [['$','pr'], []] ]  # null projection #

[ 'op', '${!}', [['$','rnd_rule'], ['round_meth']] ]  # radix,min_exp #

[ 'op', '%{!}', [['$','pt'], ['pno','pname','weight']] ]

[ 'op', '@{!}', [['$','pr'], ['pno','pname','weight']] ]

[ 'op', '%{%<-}', [['$','person'], 'name', ['fname','lname']] ]

[ 'op', '@{%<-}', [['$','people'], 'name', ['fname','lname']] ]

[ 'op', '%{%<-!}', [['$','person'],'all_but_name',['fname','lname']] ]

[ 'op', '@{%<-!}', [['$','people'],'all_but_name',['fname','lname']] ]

[ 'op', '%{<-%}', [['$','person'], ['fname','lname'], 'name'] ]

[ 'op', '@{<-%}', [['$','people'], ['fname','lname'], 'name'] ]

[ 'op', '@{@<-}', [['$','orders'], 'vendors', ['vendor']] ]

[ 'op', '@{@<-!}', [['$','orders'], 'all_but_vendors', ['vendor']] ]

[ 'op', '@{<-@}', [['$','orders'], ['vendor'], 'vendors'] ]

[ 'op', '@{#@<-!}',
    [['$','people'], 'count_per_age_ctry', ['age','ctry']] ]

[ 'op', '.[]', [['$','ary'], 3] ]

[ 'op', '[]', [['$','ary'], 10..14] ]

Rational Operators That Do Rounding

A rat_op_invo_with_round node has exactly 2-3 main op args, each of which is an expr node that defines an input value for the operator. When there are 2 main op args, the first and second args are expr and round_rule, respectively. When there are 3 main op args, the first, second and third args are lhs, rhs and round_rule, respectively.

Examples:

[ 'op', 'round', [['$','foo'], :RatRoundRule[10,-2,'HalfEven']] ]

[ 'op', 'N^', [ 2.0, 0.5, :RatRoundRule[2,-7,'ToZero'] ] ]

[ 'op', 'log', [ 309.1, 5.4, :RatRoundRule[10,-4,'HalfUp'] ] ]

[ 'op', 'e^', [ 6.3, :RatRoundRule[10,-6,'ToCeiling'] ] ]

[ 'op', 'log-e', [ 17.0, :RatRoundRule[3,-5,'ToFloor'] ] ]

Order Comparison Operators

An ord_compare_op_invo node has exactly 2 or 3 or 2-N main op args, depending on the op, each of which is an expr node. When the op requires exactly 2 main op args, the first and second args are lhs and rhs, respectively. When the op requires exactly 2 main op args, the first, second and third args are min, expr, and max, respectively. When the op is N-adic, requiring 2-N main op args, then the order of the main op args isn't significant. Note that for an N-adic op, the main op args may alternately be given as a Perl Set|KeySet rather than a Perl Seq|Array. Details on the extra op args are pending.

Examples (for now sans any use of extra op args, which are atypical):

[ 'op', '<=>', [ ['$','foo'], ['$','bar'] ] ]

[ 'op', 'min', [ ['$','a'], ['$','b'], ['$','c'] ] ]

[ 'op', 'max', [ ['$','a'], ['$','b'], ['$','c'] ] ]

[ 'op', '<', [ ['$','foo'], ['$','bar'] ] ]

[ 'op', '>', [ ['$','foo'], ['$','bar'] ] ]

[ 'op', '≤', [ ['$','foo'], ['$','bar'] ] ]

[ 'op', '≥', [ ['$','foo'], ['$','bar'] ] ]

[ 'op', 'I∈', [ ['$','a'], 1..5 ] ]

[ 'op', '≤≤', [ ['$','min'], ['$','foo'], ['$','max'] ] ]

[ 'op', '≤<', [ ['$','min'], ['$','foo'], ['$','max'] ] ]

[ 'op', '!<≤', [ ['$','min'], ['$','foo'], ['$','max'] ] ]

[ 'op', '!<<', [ ['$','min'], ['$','foo'], ['$','max'] ] ]

TEMPORAL EXTENSION OPAQUE VALUE LITERALS

When this extension is active, there exist 5 additional varieties of value node: TAIInstant, TAIDuration, UTCInstant, FloatInstant, UTCDuration. Also, between these 5 varieties, these 11 additional values are allowed for value's value_kind attribute: TAIInstant, TAIDuration, UTC[Instant|DateTime|Date|Time], Float[Instant|DateTime|Date|Time], UTCDuration. For all of these varieties, the value_kind may not be omitted.

Date and Time Literals

A TAIInstant node represents a single point in time which is specified in terms of atomic seconds. This node is interpreted as a Muldis D sys.std.Temporal.Type.TAIInstant value as follows: The payload must be a Perl Instant, which is mapped directly.

A TAIDuration node represents a single amount of time (the difference between two instants) which is specified in terms of atomic seconds. This node is interpreted as a Muldis D sys.std.Temporal.Type.TAIDuration value as follows: The payload must be a Perl Duration, which is mapped directly.

A UTCInstant node represents an "instant"/"datetime" value that is affiliated with the UTC time-zone. This node is interpreted as a Muldis D sys.std.Temporal.Type.UTCInstant value whose instant possrep attribute values are defined as follows:

The payload must be a Perl Seq|Array with 6 elements, where each element may be either undefined or defined; or if fewer than 6 elements are provided, the Seq|Array will be implicitly extended to 6, filling with undefs. The 6 payload elements correspond in order, from the lowest to the highest indexed, to the 6 attributes: year, month, day, hour, minute, second. For each payload element that Perl considers undefined or defined, the corresponding attribute has the Nothing or a Single value, respectively. For each of the first 5 elements, when it is defined, it must qualify as a valid payload for an Int node; for the 6th element, when it is defined, it must qualify as a valid payload for a Rat node.

A defined year may be any integer, each of [month, day] must be a positive integer, each of [hour, minute] must be a non-negative integer, and second must be a non-negative rational number. If all 6 attributes are defined, then the new UTCInstant value is also a UTCDateTime; if just the first 3 or last 3 are defined, then the value is not a UTCDateTime but rather a UTCDate or UTCTime, respectively; if any other combination of attributes are defined, then the value is just a UTCInstant and not of any of the other 3 subtypes.

A FloatInstant node represents an "instant"/"datetime" value that is "floating" / not affiliated with any time-zone. This node is interpreted as a Muldis D sys.std.Temporal.Type.FloatInstant value in an identical fashion to how a UTCInstant node is interpreted, whose format it completely shares. Likewise regarding Float[DateTime|Date|Time].

A UTCDuration node represents a duration value, an amount of time, which is not fixed to any instant in time. This node is interpreted as a Muldis D sys.std.Temporal.Type.UTCDuration value whose duration possrep attribute values are defined as follows:

The payload must be a Perl Seq|Array with 6 elements, where each element may be either undefined or defined; or if fewer than 6 elements are provided, the Seq|Array will be implicitly extended to 6, filling with undefs. The 6 payload elements correspond in order, from the lowest to the highest indexed, to the 6 attributes: years, months, days, hours, minutes, seconds. For each payload element that Perl considers undefined or defined, the corresponding attribute has the Nothing or a Single value, respectively. For each of the first 5 elements, when it is defined, it must qualify as a valid payload for an Int node; for the 6th element, when it is defined, it must qualify as a valid payload for a Rat node.

A defined [years, months, days, hours, minutes] may be any integer, and seconds may be any rational number. Currently, UTCDuration has no system-defined subtypes, but that may change later.

Examples TODO: What is t actual syntax for P6 [Instant|Duration] types?:

:TAIInstant( Instant.new(1235556432.0) )

Instant.new(854309115.0)

:TAIDuration( Duration.new(3600.0) )

Duration.new(-50.0)

Duration.new(3.14159)

Duration.new(:2<1011101101> * :2<10> ** :2<-11011>)

Duration.new(1/43)

:UTCInstant[1964,10,16,16,12,47.5] # a UTCDateTime #

:UTCInstant[2002,12,6] # a UTCDate #

:UTCInstant[undef,undef,undef,14,2,29.0] # a UTCTime #

:FloatInstant[2003,4,5,2] # min,sec unknown or N/A #

:FloatInstant[1407] # just know its sometime in 1407 #

:UTCDuration[3,5,1,6,15,45.000012]

AUTHOR

Darren Duncan (darren@DarrenDuncan.net)

LICENSE AND COPYRIGHT

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

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

TRADEMARK POLICY

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

ACKNOWLEDGEMENTS

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

To install Muldis::D, copy and paste the appropriate command in to your terminal.

cpanm

cpanm Muldis::D

CPAN shell

perl -MCPAN -e shell
install Muldis::D

For more information on module installation, please visit the detailed CPAN module installation guide.

	Global
`s`	Focus search bar
`?`	Bring up this help dialog

	GitHub
`g` `p`	Go to pull requests
`g` `i`	go to github issues (only if github is preferred repository)

	POD
`g` `a`	Go to author
`g` `c`	Go to changes
`g` `i`	Go to issues
`g` `d`	Go to dist
`g` `r`	Go to repository/SCM
`g` `s`	Go to source
`g` `b`	Go to file browse

	Search terms
module: (e.g. module:Plugin)
distribution: (e.g. distribution:Dancer auth)
author: (e.g. author:SONGMU Redis)
version: (e.g. version:1.00)

NAME

VERSION

PREFACE

DESCRIPTION

GENERAL STRUCTURE

START

LANGUAGE NAME

CATALOG ABSTRACTION LEVELS

the_floor

code_as_data

plain_rtn_inv

rtn_inv_alt_syn

OPERATOR CHARACTER REPERTOIRE

basic

extended

STANDARD SYNTAX EXTENSIONS

temporal

VALUE LITERALS AND SELECTORS

Value Literal Common Elements

OPAQUE VALUE LITERALS

Boolean Literals

Order-Determination Literals

Rational Rounding Method Literals

General Purpose Integer Numeric Literals

General Purpose Rational Numeric Literals

General Purpose Binary String Literals

General Purpose Character String Literals

DBMS Entity Name Literals

Code Comment Literals

Rational Rounding Rule Literals

COLLECTION VALUE SELECTORS

Scalar Selectors

Tuple Selectors

Database Selectors

Relation Selectors

Set Selectors

Maybe Selectors

Array Selectors

Bag Selectors

Interval Selectors

DEPOT SPECIFICATION

MATERIAL SPECIFICATION

Material Specification Common Elements

Function Specification

Updater Specification

Procedure Specification

Scalar Type Specification

Tuple Type Specification

Relation Type Specification

Domain Type Specification

Subset Type Specification

Mixin Type Specification

GENERIC VALUE EXPRESSIONS

Generic Expression Attribute Accessors

Generic Function Invocation Expressions

Generic If-Else Expressions

Generic Given-When-Default Expressions

Library Entity Reference Selector

FUNCTION INVOCATION ALTERNATE SYNTAX EXPRESSIONS

Simple Commutative N-adic Infix Reduction Operators

Simple Non-commutative N-adic Infix Reduction Operators

Simple Symmetric Dyadic Infix Operators

Simple Non-symmetric Dyadic Infix Operators

Simple Monadic Prefix Operators

Simple Monadic Postfix Operators

Simple Postcircumfix Operators

Rational Operators That Do Rounding

Order Comparison Operators

TEMPORAL EXTENSION OPAQUE VALUE LITERALS

Date and Time Literals

SEE ALSO

AUTHOR

LICENSE AND COPYRIGHT

TRADEMARK POLICY

ACKNOWLEDGEMENTS

Module Install Instructions