ref: 8775024dce46b5ba730b8f892111d9d7b7c56a66
dir: /doc/lang.txt/
The Myrddin Programming Language
Jul 2012
Updated Dec 2016
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. File Structure
3.3. Declarations
3.4. Packages and Uses
3.5. Scoping
4. TYPES
4.1. Type Definitions
4.2. Traits and Impls
4.3. Generics
4.4. Type Inference
5. VALUES AND EXPRESSIONS
5.1. Literal Values
5.2. Expressions
5.3. Control Constructs
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, low-level programming
language. It is designed to provide the programmer with
predictable behavior and a transparent compilation model,
while at the same time providing the benefits of strong type
checking, generics, type inference, and similar. Myrddin is
not a language designed to explore the forefront of type
theory or compiler technology. It is not a language that is
focused on guaranteeing perfect safety. Its focus is on being
a practical, small, fairly well defined, and easy to
understand language for work that needs to be close to the
hardware.
Myrddin is a computer language 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.
token: /regex/ | "quoted" | <english 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 ommitted in this description.
To put it 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.
Productions are defined by any number of expressions, in which
expressions are '|' separated sequences of terms.
Terms can 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:
Anything specified here 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. There are
comments, identifiers, keywords, punctuation, and whitespace.
Comments begin with "/*" and end with "*/". They may nest.
/* this is a comment /* with another inside */ */
Identifiers begin with any alphabetic character or underscore, and
continue with alphanumeric characters or underscores. Currently the
compiler places a limit of 1024 bytes on the length of the identifier.
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
castto 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. File Structure:
file: (decl | package | use | implstmt | 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 values from a file. As
part of compilation, all the exported names 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, which are attributes on types that
may be implemented by impl functions. They define required
functions on the type.
- Impl Statements:
These define implementations of traits, allowing an
existing trait to be attached to an existing type.
3.3. Declarations:
decl: attrs ("var" | "const" | "generic") decllist
attrs: ("exern" | "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. One thing
you may note is that unlike most other languages, there is no
special function declaration syntax. Instead, a function is
declared like any other value: by assigning its name to a
constant or variable.
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.
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
bareuse: use ident
quoteuse: use "<quoted string>"
pkgdef: "pkg" ident = decl* ";;"
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 defined. This decision allows for slightly
strange code, but allows for mutually recursive functions with no
forward declarations or special cases.
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, 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:
When a closure is created, it captures all of the variables
that it refers to in its scope by value. This allows for
simple heapification of the closure.
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:
4.1. Data Types:
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.1. Primitive types:
void
bool char
int8 uint8
int16 uint16
int32 uint32
int64 uint64
int uint
long ulong
float32 float64
'void' is a type and a value although for the sake of
genericity, you can assign between void types, return values
of void, and so on. This allows generics to not have to
somehow work around void being a toxic type. The void value is
named `void`.
It is interesting to note that these types are not keywords,
but are instead merely predefined identifiers in the type
namespace.
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 can be assigned integer
literals, tested against, compared, and all the other usual
numeric types.
The various [u]intXX types hold, as expected, signed and
unsigned integers of the named sizes respectively.
Similarly, floats hold floating point types with the
indicated precision.
var x : int declare x as an int
var y : float32 declare y as a 32 bit float
4.1.2. Composite types:
pointer
slice array
Pointers are, as expected, values that hold the address of
the pointed to value. They are declared by appending a '#'
to the type. Pointer arithmetic is not allowed. They are
declared by appending a '#' to the base type
Arrays are a group of N values, where N is part of the type.
Arrays of different sizes are incompatible. Arrays in
Myrddin, unlike many other languages, are passed by value.
They are declared by appending a '[SIZE]' to the base type.
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[123] type: array of 123 foo
foo[,] type: slice of foo
4.1.3. Aggregate types:
tuple struct
union
Tuples are the traditional product type. They are declared
by putting the comma separated list of types within square
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 the traditional sum type. They consist of a tag
(a keyword prefixed with a '`' (backtick)) indicating their
current contents, and a type to hold. They are declared by
placing the keyword 'union' before a list of tag-type pairs.
They may also omit the type, in which case, the tag is
sufficient to determine which option was selected.
[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 float32 named, but they are tagged.
;;
4.1.4. Generic types:
tyvar typaram
tyname
A tyname is a named type, similar to a typedef in C, however
it genuinely creates a new type, and not an alias. There are
no implicit conversions, but a tyname will inherit all
constraints of its underlying type.
A typaram is a parametric type. It is used in generics as
a placeholder for a type that will be substituted in later.
It is an identifier prefixed with '@'. These are only valid
within generic contexts, and may not appear elsewhere.
A tyvar is an internal implementation detail that currently
leaks in error messages out during type inference, and is a
major cause of confusing error messages. It should not be in
this manual, except that the current incarnation of the
compiler will make you aware of it. It looks like '@$type',
and is a variable that holds an incompletely inferred type.
type mine = int creates a tyname named
'mine', equivalent to int.
@foo creates a type parameter
named '@foo'.
4.2. Type Inference:
The myrddin type system is a system similar to the Hindley Milner
system, however, types are not implicitly generalized. Instead, type
schemes (type parameters, in Myrddin lingo) must be explicitly provided
in the declarations. For purposes of brevity, instead of specifying type
rules for every operator, we group operators which behave identically
from the type system perspective into a small set of classes. and define
the constraints that they require.
Type inference in Myrddin operates as a bottom up tree walk,
applying the type equations for the operator to its arguments.
It begins by initializing all leaf nodes with the most specific
known type for them as follows:
4.6.1 Types for leaf nodes:
Variable Type
----------------------
var foo $t
A type variable is the most specific type for a declaration
or function without any specified type
var foo : t t
If a type is specified, that type is taken for the
declaration.
"asdf" byte[:]
String literals are byte arrays.
'a' char
Char literals are of type 'char'
void void
void is a literal value of type void.
true bool
false bool
true/false are boolean literals
123 $t::(integral,numeric)
Integer literals get a fresh type variable of type with
the constraints for int-like types.
123.1 $t::(floating,numeric)
Float literals get a fresh type variable of type with
the constraints for float-like types.
{a,b:t; } ($a,t -> $b)
Function literals get the most specific type that can
be determined by their signature.
num-binop:
+ - * / %
+= -= *= /= %
Number binops require the constraint 'numeric' for both the
num-unary:
- +
Number binops require the constraint 'numeric'.
int-binop:
| & ^ << >>
|= &= ^= <<= >>
int-unary:
~ ++ --
bool-binop:
|| && == !=
< <= > >=
5. VALUES AND EXPRESSIONS:
5.2. Literal Values
5.1.1. Atomic Literals:
literal: strlit | chrlit | floatlit |
boollit | voidlit | intlit |
funclit | seqlit | tuplit
strlit: \"(byte|escape)*\"
chrlit: \'(utf8seq|escape)\'
char: <any byte value>
escape: <any escape sequence>
intlit: "0x" digits | "0o" digits | "0b" digits | digits
floatlit: digit+"."digit+["e" digit+]
boollit: "true"|"false"
voidlit: "void"
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.
eg: 0x123_fff, 0b1111, 0o777, 1234
Integer literals have the type `@a::(numeric,integral)`.
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.
eg: 123.456, 10.0e7, 1_000.
Floating point literals have the type `@a::(numeric,floating)`.
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 ".
eg: "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.
eg: "foo" \
"bar"
String literals have the type `byte[:]`
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.
eg: 'א', '\n', '\u{1234}'
Character literals have the type `char`
Boolean literals are either the keyword "true" or the keyword
"false".
eg: true, false
Boolean literals have the type `bool`
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. They are '['-bracketed expressions, and are evaluated
Tuple literals are similarly used to initialize a tuple.
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.
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")
5.1.3. Function Literals:
funclit: "{" arglist "\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 thes 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}
}
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.
eg: :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
IEE754 rules.
The operators are listed below in order of precedence, and a short
summary of what they do is listed given. For the sake of clarity, 'x'
will stand in for any expression composed entirely of subexpressions
with higher precedence than the current current operator. 'e' will
stand in for any expression. 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 13:
x Atomic expression
literal Atomic expression
(expr) Atomic expression
Precedence 12:
x.name Member lookup
x++ Postincrement
x-- Postdecrement
x# Dereference
x[e] Index
x[lo:hi] Slice
x(arg,list) Call
Precedence 11:
&x Address
!x Logical negation
~x Bitwise negation
+x Positive (no operation)
-x Negate x
Precedence 10:
x << y Shift left
x >> y Shift right
Precedence 9:
x * y Multiply
x / y Divide
x % y Modulo
Precedence 8:
x + y Add
x - y Subtract
Precedence 7:
x & y Bitwise and
Precedence 6:
x | y Bitwise or
x ^ y Bitwise xor
Precedence 5:
`Name x Union construction
Precedence 4:
x == x Equality
x != x Inequality
x > x Greater than
x >= x Greater than or equal to
x < x Less than
x <= x 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. Atomic Expressions:
atomicexpr: ident | gap | literal | "(" expr ")" |
"sizeof" "(" type ")" | castexpr
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 represents a location in the machine that can be stored
to persistently and manipulated by the programmer. An obvious
example of this would be a variable name, although
5.2.3. Cast Expressions:
Cast expressions convert a value from one type to another.
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.4. 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 fused assignment operators are equivalent to applying the
arithmetic or bitwise operator to the lhs and rhs of the
expression before storing into the lhs.
Type:
( e1 : @a <op>= e2 : @a ) : @a
5.2.5. 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.6. 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 true, 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.7: 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.8. 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.9. 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
where @a :: numeric
5.2.10. 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.11. 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
where @a :: integral
5.2.12. 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 IEE754
rules.
Type:
( e1 : @a OP e2 : @a ) : bool
where @a :: numeric
5.2.13. 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
where @a :: numeric
5.2.14. 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
where @a :: (numeric,integral)
5.2.15. 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
where @a :: integral
5.2.16: 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
where @a :: integral
5.2.17: 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.18: Dereference:
expr#
The `#` operator refers to the value at the pointer `expr`. This
is an lvalue, and may be stored to.
Type:
(expr : @a#)# : @a
5.2.17: 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.19: 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
where @idx :: (integral,numeric)
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`, then the program must
terminate.
Type:
(expr : @a[N])[(idx : @idx)] : @a
(expr : @a[:])[(idx : @idx)] : @a
where @idx :: (integral,numeric)
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 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`.
Type:
(expr : @a[N])[(lo : @lo) : (hi : @hi)] : @a[:]
(expr : @a[:])[(lo : @lo) : (hi : @hi)] : @a[:]
(expr : @#)[(lo : @lo) : (hi : @hi)] : @a[:]
where @lo :: (integral,numeric)
and @hi :: (integral,numeric)
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.
5.3. 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.
5.5. Control Constructs:
ifstmt: "if" cond "\n" blockbody
("elif" blockbody)*
["else" blockbody] ";;"
forstmt: foriter | foreach
foreach: "for" pattern "in" expr "\n" block
foriter: "for" init "\n" cond "\n" step "\n" block
whilestmt: "while" cond "\n" block
matchstmt: "match" expr "\n" matchpat* ";;"
matchpat: "|" pat ":" blockbody
goto
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.
Blocks are the "carriers of code" in Myrddin programs. They consist
of series of expressions, typically ending with a ';;', although the
function-level block ends at the function's '}', and in if
statements, an 'elif' may terminate a block. They can contain any
number of declarations, expressions, control constructs, and empty
lines. Every control statement example below will (and, in fact,
must) have a block attached to the control statement.
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")
;;
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. Currently, only the built in sequences -- arrays
and slices -- can be iterated, however, there is work going towards
allowing user defined iterables.
for pat in 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.
Match statements do 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 can also contain
free names, 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.
Match patterns can be one of the following:
- Union patterns
These look like union constructors, only they define
a value to match against.
- Literal patterns
Any literal value can be matched against.
- Constant patterns
Any constant value can be matched against.
More types of pattern to match will be added over time.
Match statements consist of the keyword 'match', followed by
the expression to match against the patterns, followed by a
newline. The body of the match statement consists of a list
of pattern clauses. A patterned clause is a '|', followed by
a pattern, followed by a ':', followed by a block body.
An example of the syntax follows:
const Val234 = `Val 234 /* set up a constant value */
var v = `Val 123 /* set up variable to match */
match v
/* pattern clauses */
| `Val 123:
std.put("Matched literal union pat\n")
| Val234:
std.put("Matched const value pat\n")
| `Val a:
std.put("Matched pattern with capture\n")
std.put("Captured value: a = {}\n", a)
| a
std.put("A top level bind matches anything.")
| `Val 111
std.put("Unreachable block.")
;;
6. GRAMMAR:
BUGS: