ref: 96cb72770eb9c9bf3259ebb4647ef88092438808
dir: /doc/lang.txt/
The Myrddin Programming Language
Jul 2012
Updated Feb 2017
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 comatibility.
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 paramter 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 unfied 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 unfied 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
incompatility.
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 unfied. 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.
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
'#number=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 transferrable 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 funciton 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 heirarchy 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++ 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 4.2.
An identifier specifies a variable, and are looked up via
the scoping rules specified in section 4.9.
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 refering 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: 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.23: 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.24: 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 | sicetype | 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: