                    The Myrddin Programming Language
                              Jul 2012
                          Updated Jul 2018
                            Ori Bernstein

TABLE OF CONTENTS:

    1. ABOUT
    2. LEXICAL CONVENTIONS
        2.1. EBNF-ish
        2.2. As-If Rule
    3. STRUCTURE:
        3.1. Whitespace and Keywords
        3.2. Top Level Structure
        3.3. Declarations
        3.4. Packages and Uses
        3.5. Scoping
    4. TYPES
        4.1. Primitive Types
        4.2. User Defined Types
        4.3. Generic Types
        4.4. Traits and Impls
        4.5. Type Inference
        4.6. Built in Traits
    5. VALUES AND EXPRESSIONS
        5.1. Literal Values
        5.2. Expressions
    6. CONTROL FLOW
        6.1. Blocks
        6.2. Conditionals
        6.3. Matches
        6.4. Looping
        6.5. Goto
    7. GRAMMAR

1. ABOUT:

        Myrddin is designed to be a simple programming language.
        It is designed to provide the programmer with predictable
        behavior and a pragmatic set of semantics, providing the
        benefits of strong type checking, generics, type inference,
        and modern features with a high cost-benefit ratio. Myrddin
        is not a language designed to explore the forefront of type
        theory or compiler technology. Its focus is on being a
        practical, small, well defined, and easy to understand
        language for work that needs to be close to the hardware.

        Myrddin is influenced strongly by C and ML, with ideas from
        too many other places to name.


2. LEXICAL CONVENTIONS:

    2.1. EBNF-ish:

        Syntax is defined using an informal variant of EBNF (Extended
        Backus Naur Form).

            token:      /regex/ | "quoted" | <informal description>
            prod:       prodname ":" expr*
            expr:       alt ( "|" alt )*
            alt:        term term*
            term:       prod | token | group | opt | rep
            group:      "(" expr ")" .
            opt:        "[" expr "]" .
            rep:        zerorep | onerep
            zerorep:    term "*"
            onerep:     term "+"

        Whitespace and comments are implicitly stripped out before parsing.

        To put the description in words, /regex/ defines a regular
        expression that would match a single token in the input. "quoted"
        would match a single string. <english description> contains an
        informal description of what characters would match. In the case of
        ambiguity, longest match wins.  In the case of ambiguity with a
        quoted string, the quoted string wins.

        Productions are defined by any number of expressions, in which
        expressions are '|' separated sequences of terms.

        Terms are productions or tokens, and may come with a repeat specifier.
        wrapping a term in "[]" denotes that the term is repeated 0 or 1
        times. suffixing it with a '*' denotes 0 or more repetitions, and '+'
        denotes 1 or more repetitions.

    2.2. As-If Rule:

        Any behavior specified in this document may be treated however the
        compiler wishes, as long as the result is observed as if the semantics
        specified were followed strictly.

3. STRUCTURE:

    3.1. Whitespace and Keywords:

        The language is composed of several classes of tokens: comments,
        identifiers, keywords, punctuation, and whitespace.

        Comments begin with "/*" and end with "*/". This style of comment
        may nest, meaning that /* and */ still have a meaning within the
        comment. No other text in this type of comment is interpreted.

            /* this is a comment /* with another inside */ */

        Alternatively, '//' may be used to denote a comment. This comment
        will extend to the end of the current line. Newlines within a line
        comment may not be escaped. /* has no special meaning within a //
        comment.

            // this is a line comment
            // it will end on this line, regardless of the trailing \

        Identifiers begin with any alphabetic character or underscore, and
        continue with alphanumeric characters or underscores. The compiler
        may place a reasonable limit on the length of an identifier. This
        limit must be at least 256 characters.

            some_id_234__

        Keywords are a special class of identifier that is reserved by the
        language and given a special meaning. The full set of keywords are
        listed below. Their meanings will be covered later in this reference
        manual.

            $noret          _               break
            const           continue        elif
            else            extern          false
            for             generic         goto
            if              impl            in
            match           pkg             pkglocal
            sizeof          struct          trait
            true            type            union
            use             var             void
            while

        Literals are a direct representation of a data object within the
        source of the program. There are several literals implemented within
        the language.  These are fully described in section 4.2 of this
        manual. 

        Single semicolons (';') and newline (\n) characters are synonymous and
        interchangable. They both are used to mark the end of logical lines,
        and will be uniformly referred to as line terminators.

    3.2. Top Level Structure:

            file:       (decl | package | use | impldef | traitdef | tydef)*

        A file is composed of a sequence of top level elements. These
        top level elements consist of:

        - Declarations:

            These define a constant or a variable. It's worth noting
            that Myrddin has no special syntax for declaring functions,
            but instead assigns a closure to a variable or constant.

        - Package Definitions:

            These define the list of exported symbols from a file. As
            part of compilation, all the exported symbols from a package
            will get merged together from all the files being built
            into that package.

        - Use Statements:

            These import symbols for use within the file. These symbols
            come from either installed packages or files within the
            project being compiled.

        - Type Definitions:

            These define new types.

        - Trait Definitions:

            These define traits. Traits are attributes on types that
            may be implemented by impl statements. They define a
            constraint that may be set on types passed to generic
            functions, and the required functions that must be defined
            by an impl for a type to satisfy that constraint.

        - Impl Statements:

            These define implementations of traits. Impl statements
            tag a type as satisfying a trait defined by the constraint,
            and contain the code needed to implement the requirements
            imposed by the trait being implemented.

    3.3. Declarations:

            decl:       attrs declkind  decllist [traitspec]
	    declkind:   ("var" | "const" | "generic") 
            attrs:      ("extern" | "pkglocal" | "$noret")*
            decllist:   declbody ("," declbody)*
            declbody:   declcore ["=" expr]
            declcore:   name [":" type]

        A declaration consists of a declaration class (i.e., one of 'const',
        'var', or 'generic'), followed by a declaration name, optionally
        followed by a type and assignment. It is noteworthy that, unlike most
        languages, there is no function declaration syntax. Instead, a
        function is declared like any other symbol: by assigning a function
        value to a symbol.

            const:      Declares a constant value, which may not be
                        modified at run time. Constants must have
                        initializers defined.

            var:        Declares a variable value. This value may be
                        assigned to, copied from, and modified.

            generic:    Declares a specializable value. This value
                        has the same restrictions as a const, but
                        taking its address is not defined. The type
                        parameters for a generic must be explicitly
                        named in the declaration in order for their
                        substitution to be allowed.

        In addition, declarations may accept a number of modifiers which
        change the attributes of the declarations:

            extern:     Declares a variable as having external linkage.
                        Assigning a definition to this variable within the
                        file that contains the extern definition is an error.

            pkglocal:   Declares a variable which is local to the package.
                        This variable may be used from other files that
                        declare the same `pkg` namespace, but referring to
                        it from outside the namespace is an error.

            $noret:     Declares the function to which this is applied as
                        a non-returning function. This attribute is only
                        valid when applied to a function.

        The 
        Examples:

            Declare a constant with a value 123. The type is not defined,
            and will be inferred:

                const x = 123

            Declare a variable with no value and no type defined. The
            value can be assigned later (and must be assigned before use),
            and the type will be inferred.

                var y

            Declare a generic with type '@a', and assigns it the value
            'blah'. Every place that 'z' is used, it will be specialized,
            and the type parameter '@a' will be substituted.

                generic z : @a = blah

            Declare a function f with and without type inference. Both
            forms are equivalent. 'f' takes two parameters, both of type
            int, and returns their sum as an int

                const f = {a, b
                    var c : int = 42
                    -> a + b + c
                }

                const f : (a : int, b : int -> int) = {a : int, b : int -> int
                    var c : int  = 42
                    -> a + b + c
                }


    3.4. Packages and Uses

            package:        "pkg" ident = decl* ";;"
            use:            bareuse | quoteuse
            bareuse:        use ident
            quoteuse:       use "<quoted string>"


        There are two keywords for module system. 'use' is the simpler
        of the two, and has two cases:

            use syspkg
            use "localfile"

        The first form, which does not have the package name quoted, will
        search the system include paths for the package listed. It does not
        search relative to the file or the compiler working directory.

        The quoted form searches the current directory for a use file named
        "localpkg" and imports it.

        The 'pkg' keyword allows you to define a (partial) package by
        listing the symbols and types for export. For example,

            pkg mypkg =
                type mytype

                const Myconst   : int = 42
                const myfunc    : (v : int -> bool)
            ;;

        declares a package "mypkg", which defines three exports, "mytype",
        "Myconst", and "myfunc". The definitions of the values may be
        defined in the 'pkg' specification, but it is preferred to implement
        them in the body of the code for readability. Scanning the export
        list is desirable from a readability perspective.

    3.5. Scoping:

            Myrddin is a lexically scoped language, with namespaces and types
        defined in a way that facilitates separate compilation with minimal
        burden on the linker.
        
        In Myrddin, declarations may appear in any order, and be used at any
        point at which it is in scope. Any global symbols are initialized
        before the program begins. Any nonglobal symbols are initialized on
        the line where they are declared, if they have an initializer.
        Otherwise, their contents are indeterminate. This decision allows for
        slightly strange code, but allows for mutually recursive functions
        with no forward declarations or special cases. That is, functions
        may call each other without regards to order of declaration:

                const f = {; g() }
                const g = {; f() }

        3.5.1. Scope Rules:

            Myrddin follows the usual lexical scoping rules. A variable
            may be defined on any line in the program. From there, any
            expressions within that block and its sub blocks may refer
            to it.

            The variables declared in constructs starting a block are
            scoped to that block. For example, in `for var i = 0; ...`,
            the variable `i` is scoped to the body of the for loop.
            In the function `{x, y; funcbody()}`, the variables `x` and
            `y` are scoped to the body of the function.

            Variables may shadow other variables in enclosing scopes, with the
            exception of captured variables in pattern matches. The rules for
            matches are covered in depth in section 6.3, but the rationale for
            this is to prevent ambiguity when matching against defined
            constants.

        3.5.2. Capturing Variables:

            Closures are functions that can refer to variables from their
            enclosing scopes. When a closure is created, it copies the
            stack variables that are in scope by value. Global variables are
            referred to normally. The copying is intended to facilitate moving
            the closure to the heap with a simple block memory copy.

            For example:

                var x = 1
                var closure = {; -> x}
                x++
                std.put("x: {}, closure(): {}\n", x, closure())

            should output:

                x: 2, closure(): 1

        3.5.2. Namespaces:

            A namespace introduced by importing a package is gramatically
            equivalent to a struct member lookup. The namespace is not
            optional.

    3.6. Program Initialization:

        Any file may define a single function name `__init__`. This function
        will be invoked before `main` runs, and after the `__init__ `function
        for all files included through use statements.



4. TYPES:

            type:       primitivetype | compositetype | aggrtype | nametype

        The language defines a number of built in primitive types. These
        are not keywords, and in fact live in a separate namespace from
        the variable names. Yes, this does mean that you could, if you want,
        define a variable named 'int'.

        There are no implicit conversions within the language. All types
        must be explicitly cast if you want to convert, and the casts must
        be of compatible types, as will be described later.

    4.1. Primitive types:

        primitivetype:      misctype | inttype | flttype
        misctype:           "void"  | "bool" | "char" | "byte"
        inttype:            "int8"  |  "uint8" |
                            "int16" | "uint16" |
                            "int32" | "uint32" |
                            "int64" | "uint64" |
                            "int"   | "uint"
        flttype:            "flt32" | "flt64"

        It is important to note that these types are not keywords, but are
        instead merely predefined identifiers in the type namespace.

        'void' is a type containing exactly one value, `void`. It is a full
        first class value, which can be assigned between variables, stored in
        arrays, and used in any place any other type is used.  Void has size
        `0`.

        bool is a type that can only hold true and false. It can be assigned,
        tested for equality, and used in the various boolean operators.

        char is a 32 bit integer type, and is guaranteed to hold exactly one
        Unicode codepoint. It is a numeric type. 

        The various [u]intN types hold, as expected, signed and unsigned
        integers of the named sizes respectively. All arithmetic on them is
        done in complement twos of bit size N.

        Int and uint vary by machine, but are at least 32 bits in size.

        Similarly, floats hold floating point types with the indicated
        precision. They are operated on according to the IEEE754 rules.

            var x : int         declare x as an int
            var y : flt32       declare y as a 32 bit float


    4.2. User Defined Types:

        4.2.1: Composite Types

                compositetype:  ptrtype | slicetype | arraytype
                ptrtype:        type "#"
                slicetype:      type "[" ":" "]"
                arraytype:      type "[" expr "]" | type "[" "..." "]"

            Pointers are values that contain the address of the value of their
            base type. If `t` is a type, then `t#` is a `pointer to t`.

            Arrays are a sequence of N values, where N is part of the type, meaning
            that different sizes are incompatible. They are passed by value. Their
            size must be a compile time constant.

            If the array size is specified as "...", then the array has zero bytes
            allocated to store it, and bounds are not checked. This allows
            flexible arrays. Flexible arrays are arrays defined at the end of
            a struct, which do not contribute to the size of the struct. When
            allocating a struct on the heap, extra space may be reserved for
            the array, allowing variable sizes of trailing data. This is not
            used commonly, but turns out to be useful for C ABI compatibility.

            Flexible arrays can also be used another way when emulating the C
            ABI. Myrddin has no tagless unions, but because runs of flexible
            arrays take zero bytes, a union can be emulated using them.

            Slices are similar to arrays in many contemporary languages.  They are
            reference types that store the length of their contents. They are
            declared by appending a '[:]' to the base type.

                foo#        type: pointer to foo
                foo[N]      type: array size N of foo
                foo[:]      type: slice of foo

        4.2.2. Aggregate types:

                aggrtype:       tupletype | structtype | uniontype
                tupletype:      "(" (tupleelt ",")+ ")"
                structtype:     "struct" "\n" (declcore "\n"| "\n")* ";;"
                uniontype:      "union" "\n" ("`" Ident [type] "\n"| "\n")* ";;"

            Tuples are a sequence of unnamed values. They are declared by
            putting the comma separated list of types within round brackets.

            Structs are aggregations of types with named members. They are
            declared by putting the word 'struct' before a block of declaration
            cores (ie, declarations without the storage type specifier).

            Unions are a tag and body pair. The tag defines the value that may
            be held by the type at the current time. If the tag has an argument,
            then this value may be extracted with a pattern match. Otherwise, only
            the tag may be matched against.

                (int, int, char)            a tuple of 2 ints and a char

                struct                      a struct containing an int named
                    a : int                 'a', and a char named 'b'.
                    b : char
                ;;

                union                       a union containing one of
                    `Thing int              int or char. The values are not
                    `Other flt32            named, but they are tagged.
                ;;

        4.2.3. Named Types:

                tydef:          "type" ident ["(" params ")"] = type
                params:         typaram ("," typaram)*

                nametype:       name ["(" typeargs ")"]
                typeargs:       type ("," type)*


            Users can define new types based on other types. These named 
            types may optionally have parameters, which make the type into
            a parameterized type.
            
            For example:

                type size = int64

            would define a new type, distinct from int64, but inheriting
            the same traits.

                type list(@a) = struct
                    next : list(@a)#
                    val : @a
                ;;

            would define a parameterized type named `list`, which takes a single
            type parameter `@a`. When this type is used, it must be supplied a
            type argument, which will be substituted throughout the right hand
            side of the type definition. For example:

                var x : list(int)

            would specialize the above list type to an integer. All
            specializations with compatible types are compatible.

    4.3. Generic types:

            typaram:        "@" ident

        A nametype refers to a (potentially parameterized) named type, as
        defined in section 4.5.

        A typaram ("@ident") is a type parameter. It is introduced as either a
        parameter of a generic declaration, or as a type parameter in a
        defined type. It can be constrained by any number of traits, as
        described in section 4.6.

        These types must be specialized to a concrete type in order to be
        used.

            @foo                        A type parameter
                                        named '@foo'.

    4.4. Traits and Impls:

        4.4.1. Traits:

                traitdef:       "trait" ident traittypes "=" traitbody ";;"
                traittypes:     typaram ["->" type ("," type)*]
                traitbody:      (name ":" type)*

            Traits provide an interface that types implementing the trait
            must conform to. They are defined using the `trait` keyword,
            and implemented using the `impl` keyword.

            A trait is defined over a primary type, and may also define
            a number of auxiliary types that the implementation can make
            more specific. The body of the trait lists a number of
            declarations that must be implemented by the implementation of the
            trait. This body may be empty.
            
            For example:

                trait foo @a = ;;

            defines a trait named `foo`. This trait has an empty body. It
            applies over a type parameter named @a.

            The definition:

                trait foo @a -> @aux = ;;

            is similar, but also has a single auxiliary type. This type can be
            used to associate types with the primary type when the impl is
            specialized. For example:

                trait gettable @container -> @contained =
                    get : (c : @container -> @contained)
                ;;

            would define a trait that requires a get function which accepts
            a parameter of type `@container`, and returns a value of type
            `@contained`.

        4.4.2. Impls:

                implstmt:        "impl" ident impltypes traitspec "=" implbody
                impltypes:       type ["->" type ("," type)*]
                implbody:        (name [":" type] "=" expr)*

            Impls take the interfaces provided by traits, and attach them
            to types, as well as providing the concrete implementation of
            these types. The declarations are inserted into the global
            namespace.

            The declarations need not be functions, and if the types can
            be appropriately inferred, can define impl specific constants.


    4.5. Type Inference:

        Myrddin uses a variant on the Hindley Milner type system. The
        largest divergence is the lack of implicit generalization when
        a type is unconstrained. In Myrddin, this unconstrained type
        results in a failure in type checking.

        4.5.1. Initialization:

            In the Myrddin type system, each leaf expression is assigned an
            appropriate type, or a placeholder. For clarity in the
            description, this will be called a type variable, and indicated by
            `$n`, where n is an integer which uniquely identifies the type
            variable. This is an implementation detail of type inference, and
            is not accessible by users.

            When a generic type is encountered, it is freshened. Freshening a
            generic type replaces all free type parameters in the type with a
            type variable, inheriting all of the traits. So, a type '@a' is
            replaced with the type '$1', and a trait-constrained type
            '@a::foo' is replaced with a trait constrained type '$1::foo'.
            This is also done for subtypes. For example, '@a#' becomes '$t#'

            Once each leaf expression is assigned a type, a depth first walk
            over the tree is done. Each leaf's type is resolved as well as it
            can be:

                - Declarations are looked up, and their types are unified with
                variables that refer to them.
                - string, character, and boolean literals are unified with the
                specific type that represents them.
                - Types are freshened. Freshening is the process of replacing
                unbound type parameters with type variables, such that
                '@a :: integral @a, numeric @a' is replaced with the type variable
                '$n :: integral $n, numeric $n'.
                - Union tags are registered for delayed unification, with the type
                for unions being the declaration type of the variable.

            Note that a generic declaration must *not* have its type unified with
            its use until after it has been freshened. This may imply that the
            type of a generic must be registered for delayed unification.

        4.5.2. Unification:

            The core of type inference is unification. Unification makes
            two values equal. This proceeds in several cases.

                - If both types being unified are type variables,
                  then the type variables are set to be equal. The
                  set union of the required traits is attached to
                  the type variable.

                - If one type is a type variable, and the other is
                  a concrete type, then the type variable is set to
                  the concrete type. All traits on the type variable
                  must be satisfied.

                - If both types are compatible concrete types, then
                  all subtypes are unified recursively.

                - If both types are incompatible concrete types, a
                  type error is flagged.

            For example:

                unify($t1, $t2)
                        => we set $t1 = $t2

                unify($t1, int)
                        => we set $t1 = int

                unify(int, int)
                        => success, int is an int

                unify(int, char)
                        => error, char != int

                unify(list($t1), list(int)) 
                        => list is compatible, so we unify subtypes.
                           $t1 is set to int.
                           success, list($t1) is set to list(int)

            Once the types of the leaf nodes is initialized, type inference
            proceeds via unification. Each expression using the leaves is
            checked.  The operator type is freshened, and then the expressions
            are unified.

            Unification of expressions proceeds by taking the types, and
            mapping corresponding parts of the expression to each other. 
            
            For unifying two types `t1` and `t2`, the following rules are
            observed:
            
            First, the most specific mapping that has been derived is looked
            up. Then, one of the following rules are followed:

            Case 1:

                If t1 is a type variable, and t2 is a type variable, then t1
                is mapped to t2, and the list of traits from t1 is appended to
                the list of traits for t2. The delayed type for t1 is
                transferred to t2, if t2 does not have a delayed type yet.
                Otherwise, the delayed types are unified.

            Case 2: 

                If t1 is a type variable, and t2 is not a type variable, then
                t1 is checked for recursive inclusions and trait
                incompatibility.
                
                If t2 refers to t1 by value, then the type would be infinitely
                sized, and therefore the program must be rejected with a type
                error. If t2 does not satisfy all the traits that t1 requires,
                then the program must be rejected with a type error.

            Case 3:

                If the type t1 is not a type variable, and t2 is a type
                variable, then t1 and t2 are swapped, and the rules for case 2
                are applied.

            Case 4:

                If neither the type `t1` and `t2` is a variable type, then the
                following rules are applied, in order.

                    - If the types are arrays, then their sizes are checked.
                      If only one of the types has an array size inferred,
                      then the size is transferred to the other. Otherwise,
                      the sizes are verified for equality after constant
                      folding. If the sizes mismatch, then the program must be
                      rejected with a type error.

                    - If one of the types is a named type, then all the
                      parameters passed to the named type are unified
                      recursively.

                    - If the types are equivalent at the root (ie, $1# and
                      int# are both pointers at the root), then all subtypes
                      are recursively unified. The number of subtypes for both
                      types must be the same. If the types are not equivalent
                      at the root, then the program must be rejected with a
                      type error.

                    - If the base type of the expression is a union, then all
                      union tags associated with the `t1` and `t2` are unified
                      recursively.

                    - If the base type of an expression is a struct, then all
                      struct members associated with `t1` and `t2` are unified
                      recursively.

            A special case exists for variadic functions, where the type of a
            variadic functon is unified argument by argument, up to the first
            variadic argument. Any arguments which are part of the variadic
            argument list are left unconstrained.

            When all expressions are inferred, and all declaration types
            have been unified with their initializer types, then delayed
            unification is applied.

        4.5.3. Delayed Unification

            In order to allow for the assignment of literals to defined types,
            when a union literal or integer literal has its type inferred,
            instead of immediately unifying it with a concrete type, a delayed
            unification is recorded. Because checking the validity of members
            is impossible when the base type is not known, member lookups are
            also inserted into the delayed unification list.

            After the initial unification pass is complete, the delayed
            unification list is walked, and any unifications on this list
            are applied. Because a delayed unification may complete members
            and permit additional auxiliary type lookups, this step may need
            to be repeated a number of times, although this is rare: Usually
            a single pass suffices.

            At this point, default types are applied. An unconstrained type
            with type $t :: numeric $t, integral $t is replaced with int. An
            unconstrained type with $t :: numeric $t, floating $t is replaced with
            flt64.

	    As a special case, a union type declared with the form

	        type u = union
                    `Foo
		;;

            will have the default type set to the named type, and not the
            union itself. This is slightly inconsistent, but it makes the
            behavior less surprising.

    4.6. Built In Traits:

        4.6.1. numeric:

            The numeric trait is a built in trait which implies that the
            operand is a number. A number of operators require it, including
            comparisons and arithmetic operations. It is present on the types

                byte char
                int8 uint8 int16 uint16
                int32 uint32 int64 uint64
                flt32 flt64

            A user cannot currently implement this trait on their types.

        4.6.2. integral:

            The integral trait is a built in trait which implies that the
            operand is an integer. A number of operators require it, including
            bitwise operators and increments. It is implemented over the
            following types:

                byte char
                int8 uint8 int16 uint16
                int32 uint32 int64 uint64

            A user cannot currently implement this trait on their types.

        4.6.3. floating:

            The floating trait is a built in trait which implies that the
            operand is an floating point value.  It is implemented for the
            following types:

                flt32 flt64

            A user cannot currently implement this trait on their types.

        4.6.4. indexable:

            The indexable trait is a built in trait which implies that
            the index operator can be used on the type. It is implemented
            for slice and array types.

            A user cannot currently implement this trait on their types.

        4.6.5. sliceable

            The sliceable trait is a built in trait which implies that
            the slice soperator can be used on the type. It is implemented
            for slice, pointer, and array types.

            A user cannot currently implement this trait on their types.

        4.6.6. function:

            The function trait is a built in trait which implies that the
            argument is a callable function. It specifies nothing about the
            parameters, which is a significant flaw.  It is implemented for
            all function types.

            A user cannot currently implement this trait on their types.

        4.6.7. iterable:

            The iterable trait implies that a for loop can iterate over
            the values provided by this type. The iterable trait is the
            only one of the builtin traits which users can implement. It
            has the signature:

                trait iterable @it -> @val =
                    __iternext__ : (itp : @it#, valp : @val# -> bool)
                    __iterfin__ : (itp : @it#, valp : @val# -> void)
                ;;

            A for loop iterating over an iterable will call __iternext__
            to get a value for the iteration of a loop. The result of
            __iternext__ should return `true` if the loop should continue
            and `false` if the loop should stop. If the loop should
            continue, then the implementation of __iternext__ should store
            the value for the next loop interation into val#.

            __iterfin__ is called at the end of the loop to do any cleanup
            of resources set up by __iternext__.

            The iterable trait is implemented for slices and arrays.

5. VALUES AND EXPRESSIONS

    5.1. Literal Values

        5.1.1. Atomic Literals:

                literal:    strlit | chrlit | intlit |
                            boollit | voidlit | floatlit |
                            funclit | seqlit | tuplit

                strlit:     \"(byte|escape)*\"
                chrlit:     \'(utf8seq|escape)\'
                char:       <any byte value>
                boollit:    "true"|"false"
                voidlit:    "void"
                escape:     <any escape sequence>
                intlit:     "0x" digits | "0o" digits | "0b" digits | digits
                floatlit:   digit+"."digit+["e" digit+]

            5.1.1.1. String Literals:

                String literals represent a compact method of representing a
                byte array. Any byte values are allowed in a string literal,
                and will be spit out again by the compiler unmodified, with
                the exception of escape sequences.

                There are a number of escape sequences supported for both character
                and string literals:
                    \n          newline
                    \r          carriage return
                    \t          tab
                    \b          backspace
                    \"          double quote
                    \'          single quote
                    \v          vertical tab
                    \\          single slash
                    \0          nul character
                    \xDD        single byte value, where DD are two hex digits.
                    \u{xxx}     unicode escape, emitted as utf8.

                String literals begin with a ", and continue to the next
                unescaped ".

                    e.g. "foo\"bar"

                Multiple consecutive string literals are implicitly merged to create
                a single combined string literal. To allow a string literal to span
                across multiple lines, the new line characters must be escaped.
                
                    e.g. "foo" \
                        "bar"

                They have the type `byte[:]`

            5.1.1.2. Character Literals:

                Character literals represent a single codepoint in the
                character set. A character starts with a single quote,
                contains a single codepoint worth of text, encoded either as
                an escape sequence or in the input character set for the
                compiler (generally UTF8).  They share the same set of escape
                sequences as string literals.

                    e.g. 'א', '\n', '\u{1234}'

                They have the type `char`.

            5.1.1.3. Integer Literals

                Integers literals are a sequence of digits, beginning with a digit
                and possibly separated by underscores. They may be prefixed with
                "0x" to indicate that the following number is a hexadecimal value,
                0o to indicate an octal value, or 0b to indicate a binary value.
                Decimal values are not prefixed.

                    e.g. 0x123_fff, 0b1111, 0o777, 1234

                They have the type `@a :: numeric @a, integral @a

            5.1.1.4: Boolean Literals:

                Boolean literals are spelled `true` or `false`.
                Unsurprisingly, they evaluate to `true` or `false`
                respectively.

                    e.g. true, false

                They have the type `bool`

            5.1.1.5: Void Literals:

                Void literals are spelled `void`. They evaluate to the void
                value, a value that takes zero bytes storage, and contains
                only the value `void`. Like my soul.

                    e.g. void

                They have type `void`.

            5.1.1.6: Floating point literals:

                Floating-point literals are also a sequence of digits beginning with a
                digit and possibly separated by underscores. Floating point
                literals are always in decimal.

                    e.g. 123.456, 10.0e7, 1_000.

                They have type `@a :: numeric @a, floating @a`


        5.1.2. Sequence and Tuple Literals:
            
                seqlit:     "[" structelts | arrayelts "]"
                tuplit:     "(" tuplelts ")"

                structelts: ("." ident "=" expr)+
                arrayelts:  ("." "[" expr "]" "=" expr | expr)*
                tupelts:    expr ("," expr)* [","]

            Sequence literals are used to initialize either a structure
            or an array. Both structure and array literals are bracketed
            by square brackets. Tuple literals are used to initialize a
            tuple, and are bracketed by parentheses.

            Struct literals describe a fully initialized struct value.
            A struct must have at least one member specified, in
            order to distinguish them from the empty array literal. All
            members which are designated with a `.name` expression are
            initialized to the expression passed. If an initializer is
            omitted, then the value is initialized to the zero value for
            that type.

            Sequence literals describe either an array or a structure
            literal. They begin with a '[', followed by an initializer
            sequence and closing ']'. For array literals, the initializer
            sequence is either an indexed initializer sequence[4], or an
            unindexed initializer sequence. For struct literals, the
            initializer sequence is always a named initializer sequence.

            All elements not initialized in the literal expression are
            filled with zero bytes.

            An unindexed initializer sequence is simply a comma separated
            list of values. An indexed initializer sequence contains a
            '.[index]=value' comma separated sequence, which indicates the
            index of the array into which the value is inserted. A named
            initializer sequence contains a comma separated list of
            '.name=value' pairs.


            A tuple literal is a parentheses separated list of values.
            A single element tuple contains a trailing comma.

            Example: Struct literal:
                [.a = 42, .b="str"]

            Example: Array literal:
                [1,2,3], [.[2] = 3, .[1] = 2, .[0] = 1], []

            Example: Tuple literals:
                (1,), (1,'b',"three")

            A tuple has the type of its constituent values grouped
            into a tuple:

                (@a, @b, @c, ..., @z)


        5.1.3. Function Literals:

                funclit:        "{" arglist ["->" rettype] [traitspec] "\n"
		                blockbody "}"
                arglist:        (ident [":" type])*

            Function literals describe a function. They begin with a '{',
            followed by a newline-terminated argument list, followed by a
            body and closing '}'. These may be specified at any place that
            an expression is specified, assigned to any variable, and are
            not distinguished from expressions in any significant way.

            Function literals may refer to variables outside of their scope.
            These are treated differently in a number of ways. Variables with
            global scope are used directly, by value.
            
            If a function is defined where stack variables are in scope,
            and it refers to them, then the stack variables shall be copied
            to an environment on the stack. That environment is scoped to
            the lifetime of the stack frame in which it was defined. If it
            does not refer to any of its enclosing stack variables, then
            this environment will not be created or accessed by the function.

            This environment must be transferable to the heap in an
            implementation specific manner.

            Example: Empty function literal:
                {;}

            Example: Function literal

                {a : int, b
                    -> a + b
                }

            Example: Nested function with environment:

                const fn = {a
                    var b = {; a + 1}
                }

            A function literal's arity is the same as the number of arguments
            it takes. The type of the function argument list is derived from
            the type of the arguments. The return type may be provided, or
            can be left to type inference.

        5.1.4: Labels:

                label:  ":" ident
                goto:   "goto" ident

            Finally, while strictly not a literal, it's not a control
            flow construct either. Labels are identifiers preceded by
            colons.

                e.g. :my_label

            They can be used as targets for gotos, as follows:

                goto my_label

            the ':' is not part of the label name.

    5.2. Expressions:

        5.2.1. Summary and Precedence:

                expr:              expr <binop> expr | prefixexpr | postfixexpr
                postfixexpr:       <prefixop> postfixexpr
                prefixexpr:        atomicexpr <unaryop>

            Myrddin expressions should be fairly familiar to most programmers.
            Expressions are represented by a precedence sorted hierarchy of
            binary operators. These operators operate on prefix expressions,
            which in turn operate on postfix expressions. And postfix
            expressions operate on parenthesized expressions, literals, or
            values.

            For integers, all operations are done in complement twos
            arithmetic, with the same bit width as the type being operated on.
            For floating point values, the operation is according to the
            IEEE754 rules.

            The operators are listed below in order of precedence, and a short
            summary of what they do is given. For simplicity, 'x' and 'y' fill
            in for any expression composed of operators with higher precedence
            than the operator defined. Similiarly, 'e' will stand in for any
            valid expression, regardless of precedence. Assignment is right
            associative. All other expressions are left associative.

            Arguments are evaluated in the order of associativity. That is,
            if an operator is left associative, then the left hand side of
            the operator will be evaluated before the right side. If the
            operator is right associative, the opposite is true.

            The specific semantics are covered in later parts of section 5.2.

            Precedence 11:
                    x.name          Member lookup
                    x.N             Tuple component access
                    x++             Postincrement
                    x--             Postdecremendoc/libstd/varargst
                    x#              Dereference
                    x[e]            Index
                    x[lo:hi]        Slice
                    x(arg,list)     Call

            Precedence 10:
                    &x              Address
                    !x              Logical negation
                    ~x              Bitwise negation
                    +x              Positive (no operation)
                    -x              Negate x
                    `Tag val        Union constructor

            Precedence 9:
                    x << y          Shift left
                    x >> y          Shift right

            Precedence 8:
                    x * y           Multiply
                    x / y           Divide
                    x % y           Modulo

            Precedence 7:
                    x + y           Add
                    x - y           Subtract

            Precedence 6:
                    x & y           Bitwise and

            Precedence 5:
                    x | y           Bitwise or
                    x ^ y           Bitwise xor

            Precedence 4:
                    x == y          Equality
                    x != y          Inequality
                    x > y           Greater than
                    x >= y          Greater than or equal to
                    x < y           Less than
                    x <= y          Less than or equal to

            Precedence 3:
                    x && y          Logical and

            Precedence 2:
                    x || y          Logical or

            Precedence 1: Assignment Operators
                    x = y           Assign                  Right assoc
                    x += y          Fused add/assign        Right assoc
                    x -= y          Fused sub/assign        Right assoc
                    x *= y          Fused mul/assign        Right assoc
                    x /= y          Fused div/assign        Right assoc
                    x %= y          Fused mod/assign        Right assoc
                    x |= y          Fused or/assign         Right assoc
                    x ^= y          Fused xor/assign        Right assoc
                    x &= y          Fused and/assign        Right assoc
                    x <<= y         Fused shl/assign        Right assoc
                    x >>= y         Fused shr/assign        Right assoc

            Precedence 0:
                    -> x            Return expression

        5.2.2. Lvalues and Rvalues:

            Expressions can largely be grouped into two categories: lvaues and
            rvalues. Lvalues are expressions that may appear on the left hand
            side of an assignment. Rvalues are expressions that may appear on
            the right hand side of an assignment. All lvalues are also
            rvalues.

            Lvalues consist of the following expressions:

                - Variables.
                - Gaps.
                - Index Expressions
                - Pointer Dereferences
                - Member lookups.
                - Tuple constructors

            Assigning to an lvalue stores the value on the rhs of the
            expression into the location designated by the lhs, with the
            exception of gaps and tuple constructors.

            Assigning into a gap lvalue discards it.
            
            When assigning to a tuple constructor, the rhs of the expression
            is broken up elementwise and stored into each lvalue of the tuple
            constructor element by element. For example:

                (a, b#, _) = tuplefunc()

            will store the first element of the tuple returned by tuplefunc
            into a, the second into b#, and the third into the gap.

        5.2.3. Atomic Expressions:
            
                atomicexpr:     ident | gap | literal | "(" expr ")" | 
                                "sizeof" "(" type ")" | castexpr |
                                "impl" "(" name "," type ")"
                castexpr:       "(" expr ":" type ")"
                gap:            "_"

            Atomic expressions are the building blocks of expressions, and
            are either parenthesized expressions or directly represent
            literals. Literals are covered in depth in section 5.1.

            An identifier specifies a variable, and are looked up via
            the scoping rules specified in section 3.5.

            Gap expressions (`_`) represent an anonymous sink value. Anything
            can be assigned to a gap, and it may be used in pattern matching.
            It is equivalent to creating a new temporary that is never read
            from whenever it is used. For example:

                _ = 123

            is equivalent to:
                
                var anon666 = 123

            In match contexts, it is equivalent to a fresh variable in the
            match, again, given that it is never read from in the body of the
            match.

            An impl expression chooses the implementation of the given trait
            declaration for the given type. It is useful for referring to trait
            declarations in a generic context. It also allows you to
            disambiguate a trait declaration whose type does not refer to the
            trait parameter.

        5.2.4. Cast Expressions:

            Cast expressions convert a value from one type to another.  Some
            conversions may lose precision, others may convert back and forth
            without data loss. The former case is referred to as lossy
            conversion. The latter case is known as round trip conversion.

            Casting proceeds according to the following rules:


                SType   DType        Action
                -------------------------------------------------------------
                int/int Conversions
                -------------------------------------------------------------
                intN    intK        If n < k, sign extend the source
                                    type, filling the top bits with the
                                    sign bit of the source until it is the
                                    same width as the destination type.

                                    if n > k, truncate the top bits of the
                                    source to the width of the destination
                                    type.

                uintN  uintK        If n < k, zero extend the source
                                    type, filling the top bits with zero
                                    until it is the same width as the
                                    destination type.

                                    If n > k, truncate the top bits of the
                                    source to the width of the destination
                                    type.
                -------------------------------------------------------------
                int/float conversions
                -------------------------------------------------------------
                intN    fltN        The closest representable integer value
                                    to the source should be stored in the
                                    destination.

                uintN   fltN        The closest representable integer value
                                    to the source should be stored in the
                                    destination.

                fltN    intN        The closest representable integer value
                                    to the source should be stored in the
                                    destination.

                fltN    uintN       The closest representable integer value
                                    to the source should be stored in the
                                    destination.
                -------------------------------------------------------------
                int/pointer conversions
                -------------------------------------------------------------
                intN   T#           Extend the source value to the width
                                    of a pointer in bits in an implementation
                                    defined manner.

                uintN  T#           Extend the source value to the width
                                    of a pointer in bits in an implementation
                                    defined manner.

                T#     intN         Convert the address of the pointer to an
                                    integer in an implementation specified
                                    manner. There should exist at least one
                                    integer type for which this conversion
                                    will round trip.

                T#     uintN        Convert the address of the pointer to an
                                    integer in an implementation specified
                                    manner. There should exist at least one
                                    integer type for which this conversion
                                    will round trip.
                -------------------------------------------------------------
                pointer/pointer conversions
                -------------------------------------------------------------
                T#      U#          If the destination type has compatible
                                    alignment and other storage requirements,
                                    the pointer should be converted losslessly
                                    and in a round-tripping manner to point to
                                    a U. If it does not have compatible
                                    requirements, the conversion is not
                                    required to round trip safely, but should
                                    still produce a valid pointer.
                -------------------------------------------------------------
                pointer/slice conversions
                -------------------------------------------------------------
                T[:]    T#          Returns a pointer to t[0]
                -------------------------------------------------------------
                pointer/function conversions
                -------------------------------------------------------------
                (args->ret)   T#    Returns a pointer to an implementation
                                    specific value representing the executable
                                    code for the function.

                -------------------------------------------------------------
                arbitrary type conversions
                -------------------------------------------------------------
                T       U           Returns a T as a U. T must be transitively
                                    defined in terms of U, or U in terms of T
                                    for this cast to be valid.



        5.2.5. Assignments:
        
                lval = rval, lval <op>= rval

            The assignment operators group from right to left. These are the
            only operators that have right associativity. All of them require
            the left operand to be an lvalue. The value of the right hand side
            of the expression is stored on the left hand side after this
            statement has executed.

            The expression is similar to applying the expression to the lhs
            and rhs of the expression before storing into the lhs. However,
            the lvalue of the expression is evaluated fully before being
            computed and stored into, meaning that any side effects in the
            subexpressions will only be applied once.

            Type:

                ( e1 : @a <op>= e2 : @a ) : @a

        5.2.6. Logical Or:
        
                e1 || e2 

            The `||` operator returns true if the left hand side evaluates to
            true. Otherwise it returns the result of evaluating the lhs. It is
            guaranteed if the rhs is true, the lhs will not be evaluated.

            Types:

                ( e1 : bool || e2 : bool ) : bool

        5.2.7. Logical And:

                expr && expr

            The `&&` operator returns false if the left hand side evaluates to
            false. Otherwise it returns the result of evaluating the lhs. It
            is guaranteed if the rhs is false, the lhs will not be evaluated.

            The left hand side and right hand side of the expression must
            be of the same type. The whole expression evaluates to the type
            of the lhs.

            Type:

                ( e1 : bool && e2 : bool ) : bool

        5.2.8: Logical Negation:

                !expr

            Takes the boolean expression `expr` and inverts its truth value,
            evaluating to `true` when `expr` is false, and `false` when `expr`
            is true.

            Type:

                !(expr : bool) : bool

        5.2.9. Equality Comparisons:
        
                expr == expr, expr != expr

            The equality operators do a shallow identity comparison between
            types. The `==` operator yields true if the values compare equal,
            or false if they compare unequal. The `!=` operator evaluates to
            the inverse of this.
                
            Type:

                ( e1 : @a == e2 : @a ) : bool
                ( e1 : @a != e2 : @a ) : bool

        5.2.10. Relational Comparisons:
        
                expr > expr, expr >= expr, expr < expr, expr <= expr

            The relational operators (>, >=, <, <=) compare two values
            numerically. The `>` operator evaluates to true if its left
            operand is greater than the right operand. The >= operand returns
            true if the left operand is greater than or equal to the right
            operand. The `<` and `<=` operators are similar, but compare
            for less than.

            Type:

                ( e1 : @a OP e2 : @a ) : bool :: numeric @a


        5.2.11. Union Constructors:
        
                `Name expr:

            The union constructor operator takes the value in `expr` and wraps
            it in a union. The type of the expression and the argument of the
            union tag must match. The result of this expression is subject to
            delayed unification, with a default value being the type of the
            union the tag belongs to.

            Type:

                Delayed unification with the type of the union tag.

        5.2.12. Bitwise:

                expr | expr, expr ^ expr, expr & expr

            These operators (|, ^, &) compute the bitwise or, xor, and and
            of their operands respectively. The arguments must be integers.

            Type:

                (e1 : @a OP e2:@a) : @a :: integral @a

        5.2.13. Addition:
        
                expr + expr, expr - expr:

            These operators (+, -) add and subtract their operands. For
            integers, all operations are done in complement twos arithmetic,
            with the same bit width as the type being operated on. For
            floating point values, the operation is according to the IEEE754
            rules.

            Type:

                ( e1 : @a OP e2 : @a ) : bool :: numeric @a

        
        5.2.14. Multiplication and Division
        
                expr * expr, expr / expr

            These operators (+, -) multiply and divide their operands,
            according to the usual arithmetic rules.

            Type:

                ( e1 : @a OP e2 : @a ) : bool :: numeric @a

        5.2.15. Modulo:
        
                expr % expr

            The modulo operator computes the remainder of the left operand
            when divided by the right operand.

            Type:

                ( e1 : @a OP e2 : @a ) : bool :: numeric @a, integral @a

        5.2.16. Shift:

                expr >> expr, expr << expr

            The shift operators (>>, <<) perform right or left shift on their
            operands respectively. If an operand is signed, a right shift will
            shifts sign extend its operand. If it is unsigned, it will fill
            the top bits with zeros.

            Shifting by more bits than the size of the type is implementation
            defined.

            Type:

                (e1 : @a OP e2:@a) : @a :: integral @a

        5.2.17: Postincrement, Postdecrement:

                expr++, expr--

            These expressions evaluate to `expr`, and produce a decrement after
            the expression is fully evaluated. Multiple increments and
            decrements within the same expression are aggregated and applied
            together. For example:

                y = x++ + x++

            is equivalent to:

                y = x + x
                x += 2

            The operand must be integral.

            Type:

                (e1++ : @a) : @a
                (e1-- : @a) : @a
                :: integral @a

        5.2.18: Address:

                &expr

            The `&` operator computes the address of the object referred to
            by `expr`. `expr` must be an lvalue.

            Type:
            
                &(expr : @a) : @a#

        5.2.19: Dereference:

                expr#

            The `#` operator refers to the value at the pointer `expr`. This
            is an lvalue, and may be stored to.

            The pointer being dereferenced may have at some point come from a
            cast expression. It may also be constructed by arbitrary code via
            integer manipulations and system specific memory allocation.

            If this happens, there are two cases. If the pointed-to type of
            the accessing pointer is larger than the declaration type of the
            object, the behavior is undefined.  Similarly, if the pointer
            value has an incompatible alignment at runtime, the behavior is
            undefined. Otherwise, the value read back through the pointer is
            implementation specific. These system specific values may include
            trap representations.

            Type:
            
                (expr : @a#)# : @a

        5.2.20: Sign Operators:

                -expr, +expr

            The `-` operator computes the complement two negation of the value
            `expr`. It may be applied to unsigned values. The `+` operator
            only exists for symmetry, and is a no-op.

            Type:
            
                OP(expr : @a) : @a


        5.2.21: Member Lookup:

                expr.name

            Member lookup operates on two classes of types: User defined
            struct and sequences. For user defined structs, the type of `expr`
            must be a structure containing the member `name`. The result of
            the expression is an lvalue of the type of that member.

            For sequences such as slices or arrays, there is exactly one
            member that may be accessed, `len`. The value returned is the
            count of elements in the sequence.

            Type:

                (expr : <aggregate>).name : @a
                (expr : <seq>).len : @idx
                :: integral @a, numeric @a

        5.2.22: Tuple Component Access

                expr.N

            Tuple component access operates on tuples. N must be a natural
            number (i.e., 0, 1, 2, ...) and the type of `expr` must be a tuple
            type with at least `N+1` components. The result of the expression
            is an lvalue of the type of the `N+1`th component.

            Type:

                (expr : (@a0, ..., @aN, ...)).N : @aN

        5.2.23: Index:

                expr[idx]

            The indexing operator operates on slices and arrays. The
            `idx`th value in the sequence is referred to. This expression
            produces an lvalue.

            If `idx` is larger than `expr.len` or smaller than 0, then the
            program must terminate.

            Type:

                (expr : @a[N])[(idx : @idx)] : @a
                (expr : @a[:])[(idx : @idx)] : @a
                :: integral, numeric @idx

        5.2.24: Slice:

                expr[lo:hi], expr[:hi], expr[lo:], expr[:]

            The slice expression produces a sub-slice of the sequence or
            pointer expression being sliced. The lower bound is inclusive, and
            the upper bound is exclusive. The elements contained in this slice
            are expr[lo]..expr[hi-1].
            
            If the lower bound is omitted, then it is implicitly zero. If the
            upper bound is ommitted, then it is implicitly `expr.len`.

            If the bounds are not fully contained within the slice being
            indexed, the program must terminate.

            Type:

                (expr : @a[N])[(lo : @lo) : (hi : @hi)] : @a[:]
                (expr : @a[:])[(lo : @lo) : (hi : @hi)] : @a[:]
                (expr : @#)[(lo : @lo) : (hi : @hi)] : @a[:]
                :: integral, numeric @lo, integral, numeric @hi

        5.2.25: Call:

                expr()
                expr(arg1, arg2)
                expr(arg1, arg2, ...)

            A function call expression takes an expression of type
            (arg, list -> ret), and applies the arguments to it,
            producing a value of type `ret`.  The argument types and
            arity must must match, unless the final argument is of
            type `...`.

            If the final type is `...`, then the `...` consumes as many
            arguments as are provided, and passes both them and an
            implementation defined description of their types to the function.


            Type:

                (expr : @fn)(e1 : @a, e2 : @b) : @ret
                where @fn is a function of type (@a, @b -> @ret)
                or    @fn is a function of type (@a, ... -> ret)
                adjusted appropriately for arity.



6. CONTROL FLOW

    The control statements in Myrddin are similar to those in many other
    popular languages, and with the exception of 'match', there should
    be no surprises to a user of any of the Algol derived languages.

    6.1. Blocks:

            block:      blockbody ";;"
            blockbody:  (decl | stmt | tydef | "\n")*
            stmt:       goto | break | continue | retexpr | label |
                        ifstmt | forstmt | whilestmt | matchstmt

        Blocks are the basic building block of functionality in Myrddin.  They
        are simply sequences of statements that are completed one after the
        other. They are generally terminated by a double semicolon (";;"),
        although they may be terminated by keywords if they are part of a more
        complex control flow construct.

        Any declarations within the block are scoped to within the block,
        and are not accessible outside of it. Their storage duration is
        limited to within the block, and any attempts to access the associated
        storage (via pointer, for example) is not valid.

    6.2. Conditionals

            ifstmt:     "if" cond "\n" blockbody
                        ("elif" blockbody)*
                        ["else" blockbody] ";;"


        If statements branch one way or the other depending on the truth
        value of their argument. The truth statement is separated from the
        block body

            if true
                std.put("The program always get here")
            elif elephant != mouse
                std.put("...eh.")
            else
                std.put("The program never gets here")
            ;;

    6.3. Matches

            matchstmt:  "match" expr "\n" matchpat* ";;"
            matchpat:   "|" pat ":" blockbody
            pat:        expr

        Match statements perform deep pattern matching on values. They take as
        an argument a value of type 't', and match it against a list of other
        values of the same type.
        
        The patterns matched against may free variables, which will be bound
        to the sub-value matched against.  The patterns are checked in order,
        and the first matching pattern has its body executed, after which no
        other patterns will be matched. This implies that if you have specific
        patterns mixed with by more general ones, the specific patterns must
        come first.

        All potential cases must be covered exhaustively. Non-exhaustive
        matches are a compilation error.

        Match patterns can be one of the following:

            - Wildcard patterns
            - Gap patterns
            - Atomic literal patterns
            - String patterns
            - Union patterns
            - Tuple patterns
            - Struct patterns
            - Array patterns
            - Constant patterns
            - Pointer chasing patterns

        6.3.1. Wildcards and Gaps:

            Wildcard patterns an identifier that is not currently in scope.
            This variable name captures the variable. That is, in the body of
            the match, there will be a variable in scope with the same name as
            the identifier, and it will contain a copy of the value that is
            being matched against. A wildcard pattern always matches
            successfully.

            Gap patterns are identical to wildcard patterns, but they do not
            capture a copy of the value being matched against.

        6.3.2. Literal and Constant Patterns:

            Most pattern matches types are literal patterns. These are simply
            written out as a literal value of the type that is being matched
            against.

            Atomic literal patterns match on a literal value. The pattern is
            compared to the value using semantics equivalent to the `==`
            operator. If the `==` operator would return true, the match is
            successful.

            String patterns match a byte sequence. The pattern is compared to
            the value by first comparing the lengths. Then, each byte in the
            string is compared, in turn, to the byte of the pattern. If the
            length and all characters are equal, the pattern succeeds.

            Union patterns compare the union tag of the pattern wtih the union
            tag on the value. If there is a union body associated with the
            tag, then the pattern must also have a body. This is recursively
            matched on.  If the tag and the body (if present) both match, this
            match is considered successful.
            
            Tuple patterns proceed to recursively check each tuple element for
            a match. If all elements match, this is a successful match.

            Struct patterns recursively check each named member that is
            provided.  Not all named members are mandatory. If a named member
            is omitted, then it is equivalent to matching it against a gap
            pattern. If all elements match, then this is a successful match.

            Array patterns recursively check each member of the array that is
            provided. The array length must be part of the match. If all array
            elements match, then this is a successful match.

            Constant patterns use a compile time constant that is in scope for
            the pattern. The semantics are the same any of the literal
            patterns listed above.

        6.3.3. Pointer Chasing Patterns:

            Pointer chasing patterns allow matching on pointer-to-values. They
            are written with the `&` operator, as though you were taking the
            address of the pattern being matched against.

            This pattern is matched by dereferencing the value being matched,
            and recursively matching the value against the pattern being
            addressed.

            The pointer provided to a pointer chasing match must be a valid
            pointer. Providing an invalid pointer leads to undefined behavior.

        6.4.4. Examples:

            6.4.4.1. Wildcard:

                var e = 123
                match expr
                | x:    std.put("x = {}\n", x)
                ;;

            6.4.4.2. Atomic Literal:

                var e = 123
                match expr
                | 666:  std.put("wrong branch\n")
                | 123:  std.put("correct match\n")
                | _:    std.put("default branch\n")
                ;;

            6.4.4.3. Tuple Literal:

                var e = (123, 999)
                match expr
                | (123, 666):   std.put("wrong branch\n")
                | (123, 999):   std.put("right branch\n")
                | _:            std.put("default branch\n")
                ;;

            6.4.4.3. Union Literal:

                var e = `std.Some 123
                match expr
                | `std.Some 888:   std.put("wrong branch\n")
                | `std.Some 123:   std.put("right branch\n")
                | `std.Some x:     std.put("other wrong branch\n")
                | `std.None:       std.put("other wrong branch\n")
                ;;

            6.4.4.4 Struct Literal:

                type s = struct
                    x : int
                ;;

                var e : s = [.x=999]
                match expr
                | [.x=123]:   td.put("wtf, x=123\n")
                | [.x=x]:     std.put("x={}\n", x)
                ;;

            6.4.4.5 Pointer Chasing:

                type s = struct
                    x : int#
                ;;

                var p = 123
                var e : s = [.x=&p]
                match expr
                | [.x=&123]:   td.put("good, x=123\n")
                | [.x=&x]:     std.put("wtf, x={}\n", x)
                ;;


    6.4. Looping

            forstmt:    foriter | foreach
            foreach:    "for" pattern ":" expr "\n" block
            foriter:    "for" init "\n" cond "\n" step "\n" block
            whilestmt:  "while" cond "\n" block

        For statements come in two forms. There are the C style for loops
        which begin with an initializer, followed by a test condition,
        followed by an increment action. For statements run the initializer
        once before the loop is run, the test each on each iteration through
        the loop before the body, and the increment on each iteration after
        the body. If the loop is broken out of early (for example, by a goto),
        the final increment will not be run. The syntax is as follows:

            for init; test; increment
                blockbody()
            ;;

        The second form is the collection iteration form. This form allows
        for iterating over a collection of values contained within
        something which is iterable. This form of loop can be used on any
        iterable types. Iterable types are defined as slices, arrays, and any
        type that implements the builtin iterable trait.

            for pat : expr
                blockbody()
            ;;

        The pattern applied in the for loop is a full match statement style
        pattern match, and will filter any elements in the iteration
        expression which do not match the value.

        While loops are equivalent to for loops with empty initializers
        and increments. They run the test on every iteration of the loop,
        and exit only if it returns false.

    6.5. Goto

            label:      ":" ident
            goto:       goto ident

6. GRAMMAR:

    /* top level */
    file:       toplev*
    toplev:     use | pkgdef | decl | traitdef | impldef | tydef

    /* packages */
    use:       "use" ident | strlit
    pkgdef:    "pkg" [ident] "=" pkgbody ";;"
    pkgbody:   (decl | attrs tydef | traitdef | impldef)*

    /* declarations */
    decl:       attrs ("var" | "const" | "generic") decllist 
    attrs:      ("$noret" | "extern" | "pkglocal")*
    decllist:   declbody ("," declbody)+
    declbody:   declcore ["=" expr]
    declcore:   ident [":" type]

    /* traits */
    traitdef:   "trait" ident typaram [auxtypes] [traitspec] ("\n" | "=" traitbody ";;")
    auxtypes:   "->" type ("," type)*
    traitbody:  "\n"* (ident ":" type "\n"*)*
    impldef:    "impl" ident type [auxtypes] [traitspec] ("\n" | "=" implbody ";;")
    implbody:   "\n"* (ident [":" type] "=" expr "\n"*)*

    /* types */
    traitspec:  "::" traitvar+
    traitvar:   name+ type ["->" type]
    tydef:      "type" typeid [traitspec] "=" type
    typeid:     ident | ident "(" typarams ")"
    typarams:   typaram ("," typaram)*
    type:       structdef | uniondef | tupledef |
                constructed | generic | "..."
    structdef:  "struct" structbody ";;"
    structbody:	declcore*
    uniondef:   "union" unionbody ";;"
    unionbody:	("`" ident [type])*
    tupledef:   "(" type ("," type)* ")"
    generic:    typaram
    constructed: functype | slicetype | arraytype | ptrtype | void | name
    functype:   "(" arglist "->" type ")"
    arglist:    [arg ("," arg)*]
    arg:        name ":" type
    slicetype:  type "[" ":" "]"
    arraytype:  type "[" (expr | "...") "]"
    ptrtype:    type "#"
    void:       "void"

    /* expressions */
    retexpr:    "->" expr | expr
    exprln:     expr ";"
    expr:       lorepxr asnop expr | lorexpr
    lorexpr:    lorexpr "||" landexpr | landexpr
    landexpr:   landexpr "&&" cmpexpr | cmpexpr
    cmpexpr:    cmpexpr ("<" | "<=" | "==" | ">=" | ">") borexprexpr | borexpr
    borexpr:    borexpr ("|" | "^" ) bandexpr | bandexpr
    bandexpr:   bandexpr "&" addexpr | addexpr
    addexpr:    addexpr ("+" | "-") mulexpr
    mulexpr:    mulexpr ("*" | "/" | "%") shiftexpr
    shiftexpr:  shiftexpr ("<<" | ">>") prefixexpr
    preexpr:    "++" prefixexpr | "--" prefixexpr |
                "!" prefixexpr | "~" prefixexpr |
                "-" prefixexpr | "+" prefixexpr |
                "&" prefixexpr | postexpr
    postexpr:   postexpr "." ident |
                postexpr "++" | postexpr "--" |
                postexpr "[" expr "]" |
                postexpr "[" [expr] ":" [expr] "]" |
                "`" name postexpr | "`" name
                postepxr "#" |
                atomicexpr

    atomicexpr: ident | literal | "(" expr ")" | "sizeof" "(" type ")" |
                "(" expr ":" type ")" | "impl" "(" name "," type ")"

    /* literals */
    literal:    funclit | seqlit | tuplit | simplelit
    funclit:    "{" [funcargs] [traitspec] "\n" blockbody "}"
    funcargs:   ident [ ":" type] ("," ident [ ":" type])*
    seqlit:     "[" structelts | [arrayelts] "]"
    arrayelts:  arrayelt ("," arrayelt)*
    arrayelt:   ";'* expr [":" expr] ";"*
    structelts: structelt ("," ";"* structelt)*
    structelt:  ";"* "." name "=" expr ";"*
    tuplit:     "(" expr "," [expr ("," expr)*] ")"
    simplelit:  strlist | chrlit | fltlit | boollit | voidlit | intlit
    fltlit:     <float literal>
    boollit:    "true" | "false"
    voidlit:    "void"
    strlit:     <string literal>
    chrlit:     <char literal>

    /* statements */
    blkbody:    (decl | stmt | tydef | ";")*
    stmt:       jmpstmt | flowstmt | retexpr
    jmpstmt:    goto | break | continue | label
    flowstmt:   ifstmt | forstmt | whilestmt | matchstmt

    ifstmt:     "if" exprln blkbody elifs ["else" blkbody] ";;"
    elifs:      ("elif" exprln blkbody)*
    forstmt:    foriter | forstep
    foriter:    "for" expr "in" exprln blkbody ";;"
    forstep:    "for" exprln exprln exprln blkbody ";;"
    whilestmt:  "while" exprln blkbody ";;"
    matchstmt:  "match" exprln pattern* ";;"
    pattern:      "|" expr ":" blkbody ";"
    goto:       "goto" ident ";"
    break:      "break" ";"
    continue:   "continue" ";"
    label:      ":" ident ";"

    /* misc */
    name:       ident | ident "." ident
    asnop:      "=" | "+=" | "-=" | "*=" | "/=" | "%=" |
                "|=" | "^=" | "&=" | "<<=" | ">>="

    /* pattern tokens */
    typaram:    /@[a-zA-Z_][a-zA-Z0-9_]*/
    ident:      /[a-zA-Z_][a-zA-Z0-9_]*/

BUGS:

