Skip to content

Latest commit

 

History

History
601 lines (436 loc) · 21.8 KB

fuzion_reference_manual.adoc

File metadata and controls

601 lines (436 loc) · 21.8 KB
Raw

Fuzion Reference Manual [DRAFT]

1. About this Document

1.1. Audience

Caution
 NYI: Audience spec missing!

1.2. Conventions

This is work in progress. Areas where information is known to be preliminary, missing or wrong might be marked as follows:

Caution
 NYI: This spec is work in progress!

Generally, NYI is used in this document, as well as through any other files related to the Fuzion project, to mark sections that need further work or future enhancements. This is often equivalent to comments starting TODO or similar used in other projects.

The specification contains a number of rules that must be implemented by the language implementations. These rules are identified by identifiers such as DOMAIN_DETAIL. Rules are shown as follows:

2. Input

2.1. Input Sources

Fuzion source code input may come from different sources including source code files, streams such as the standard input stream of a Unix shell command, interactive input in an interactive Read-Eval-Print-Loop (REPL), command line arguments, etc.

For source code files, the following rule applies:

2.2. Directories

Source files may be organized in a hierarchy of directories. Source files in sub-directories are automatically considered as input only if corresponding outer features exist:

2.3. Input encoding

Fuzion input sources use UTF8 encoding.

Caution
 NYI: Actual Unicode version has not been fixed yet!

3. Syntax

3.1. Lexical Tokens

The Unicode code points of the input data are grouped into lexical tokens. The main groups of tokens are white space, reserved keywords, identifiers, literals and comments. The following sub-sections describe these in detail.

3.1.1. Unsupported Code Points

Certain code points are not supported and will not be converted into tokens by the lexer but instead result in an error when processing input data containing these code points. The following code points are unsupported code points.

3.1.2. White Space

White space are code points that are ignored when creating tokens. Nevertheless, white space often plays an important role in separating tokens such as a keyword from an identifier as in if condition.

The following code points in the input are considered white space.

Even though white space does directly create tokens, the Fuzion language parser is affected by the presence of white space, e.g., to group blocks of code by a common level of indentation or to separate actual arguments provided to a call.

3.1.3. Code point categories

The following code points are considered Fuzion letters:

The following code points are considered Fuzion digits:

The following code points are considered Fuzion numerics:

The following code points are considered Fuzion operator code points:

3.1.4. Lines and Columns

Each code point in an Input sources has an associated line and column. The first code point is in line 1 column 1. Each code point that is not following a end of line marker is part of the same line as the previous code point and the line of the previous code point incremented by 1.

A code point that follows an end of line marker gets its line number increased by 1 and its column reset to 1.

Note
 In Fuzion, the lines and columns are not only relevant when referring to code location, e.g., when reporting error in the source code, but also have an effect on how code is parsed: In certain contexts such as in a one-line comment or at a given indentation level, the position of code affects the way the code is parsed.

3.1.5. Keywords

The Fuzion grammar knows the following reserved keyword:

3.1.6. Identifiers

Identifiers in Fuzion are used to attach names to Fuzion features. Identifiers may contain a large variety of letters, digits and numeric symbols, they must start with a letter.

3.1.7. Operators

Similar to an identifier, a Fuzion operator may be part of a name of a Fuzion features. Such features permit a call syntax that uses infix, prefix or postfix notation.

Examples for legal operators are +, %%%, ??, ∀, ∙, --- >, /-/, //, #.

Examples for non-operators are ?, //, #*.

3.1.8. Comments

Fuzion offers three kinds of comments: single line comments that start with either # or // and that extend to the end of the source code line, and nestable comments using /* and \*/ that may extends over several lines of code.

Examples of valid comments are

i := 42     # this is a comment
this is not a comment
j := 32168  // this is also a comment
k := /* this is a comment */ 23
/* this /* comment /* is */ nested */ */
l := "not a comment, but a string literal"
m := "/* also not a comment, but a string literal */"
n := "// still a string literal"
o := "# also a string literal"
/* this
/* comment
/* extends */
   over several
*/ lines */
p := o
/*" a comment, not a string */

3.1.9. Literals

Caution
 NYI: Text Missing
Numeric Literals
Caution
 NYI: Text Missing
String Literals
Caution
 NYI: Text Missing

String literals support the following escape sequence to include special characters:

3.2. Grammar

Caution
 NYI: Text Missing

3.2.1. Redefining inherited features

If and only if a feature redefines an inherited feature, it must use the modifier redef in its declaration:

3.2.2. Redefining inherited features

Pre- and postconditions of features are introduced using the pre or post keyword if those features do not redefine an inherited feature:

In case of redefining an inhertied feature, pre- and postconditions are introduced using pre else or post then, respectively:

4. Semantics

Caution
 NYI: Text Missing

Appendix A: Glossary

Abstract Feature

An abstract feature is a feature declared using ⇒ abstract.

Actual

An actual argument is an expression that is parsed as an actual as part of a call or the right hand side of an infix operator call.

Actual Type Parameter

An actual type parameter is a type that replaces a type parameter of the feature a type is based on.

Argument

An argument is a type parameter or a field that is declared in the formArgs section of a routine.

Child

A child of a feature f is any feature g that inherits from f. A child is hence used synonymously to an heir.

Choice

A choice is either the feature choice defined in the Fuzion base library or any feature that is a type parameters and a choice may not contain code.

Choice Type

A choice type is a type that is based on a feature that is a choice.

Constructor

A constructor is a routine declared using is. A constructor has exceutable code and defines a type. On a call to a constructor, an instance of this type is created and this instance is implicitly returned as a result after execution of the constructor’s code.

Call Destination

The destination of a call t.f a b is the feature f' that was selected at runtime by dynamic dispatch depending on the call target t and the feature name given in the call.

Direct Child

A direct child of a feature p is any feature c that inherits directly from p.

Direct Inheritance

A feature f inherits directly from another feature g if f lists g in the inherits clause of its declaration.

Direct Parent

A direct parent of a feature c is any feature p such that c inherits directly from p.

Dynamic Type

The dynamic type of an expression is the runtime type of an instance produced as the result of that expression.

Dynamic Dispatch

Dynamic dispatch is a mechanism that is used at runtime to determine the destination of a call depending on the dynamic type of the target and name of the called feature.

Feature

A feature is the most fundamental entity of Fuzion. A feature can be declared and can be called. Features generalize fairly different concepts found in other programming languages such as functions, methods, constructors, classes, structs, records, packages, interfaces, fields, and local variables. A Fuzion feature may be one of the following variants: a constructor, a function, a field, a choice, a type parameter, an abstract feature, an intrinsic, a native feature, or the universe. Every feature except the universe is declared within an outer feature.

Feature Call

A feature call is an expression in Fuzion code that calls a destination feature on a given target giving zero or more actual arguments. An example is t.f a b that calls a feature with name f,2 on target t giving two actual arguments a and b.

Feature Name

A feature name is the combination of an identifier and an integer argument count.

Field

A field is a feature that is either declared using := or an argument. A field can hold an instance that is assigned to it at runtime when executing its declaration as an expression (for fields declared using :=) or when an actual argument is passed to a call. A field can be the destination of a call, execution of that call at runtime results in the instance that was assigned to that field.

Function

A function is a routine declared using ⇒. A function has exceutable code that produces a result value result and an explicit or inferred result type rt.

Function Type

A function type is any type derived from the Fuzion base library feature Function by giving actual arguments or a type that is derived from a Fuzion feature that inherits from a function type.

Inheritance

An feature f is said to inherit from a feature g if f equals g or, recursively, f inherits directly from a feature h that inherits from g.

Input Source

An input source is a stream of bytes that contains Fuzion code that is used as an input for tools like Fuzion compilers.

Instance

An instance is a value of a given runtime type. Instances exist only at runtime. Instances are created either by a call or by tagging.

Intrinsic Feature

An intrinsic feature is a feature declared using ⇒ intrinsic or ⇒ intrinsic_constructor.

Native Feature

A native feature is a feature declared using ⇒ native.

Caution
 NYI: Need more detail on native feature
Outer Instance

With the exception of the universe instance, every instance is linked to a corresponding outer instance. For the instance of a routine, the outer instance is the value of the target of the call that created the instance. The outer instance of choice instance is the universe instance.

Outer Feature

The outer feature o of a feature f is the feature that contains the declaration of f. If f is not declared inside any other feature, `f’s outer feature is the universe, which itself does not have an outer feature.

Outer Type

For any type that is based on a feature whose outer feature o exists and is not the universe, there is a corresponding outer type based on a child of o.

Parent

A parent of a feature f is any feature g such that f inherits from g. A parent is hence used synonymously to an ancestor.

Routine

A routine is a Feature declared using is or ⇒ that is neither an abstract feature, a choice, an intrinsic feature nor a native feature.

Real Child

A real child of a feature p is any feature c that inherits really from p.

Real Inheritance

An feature f is said to inherit really from a feature g if f does not equal g and f inherits from g.

Real Parent

A real parent of a feature c is any feature p such that c inherits really from p.

Result Type

A result type is static type defined for a feature that may be called.

Runtime Type

A runtime type is a type that does not contain any type parameters.

Static Type

The static type is the type of an expression or the result type of a routine or a field determined statically by tools like a Fuzion compiler.

Tagging

Tagging is the creation of an instance of a choice type during an assignment of an instance to a field.

Target

The target is part of a feature call. The dynamic type of the target together with the feature name of the call determines the destination of the call.

Type

A type is either a reference to a type parameter or based on a feature of type constructor or choice. If that feature has type parameters, a type has corresponding actual type parameters. If the base has an outer feature that is not the universe, the type has an outer type.

Type Parameter

A type parameter is an argument that can hold a runtime type value.

Unit type

A unit type is a type that contains no direct inner fields defined by a constructor whose outer feature is either the universe or itself a constructor defining a unit type.

Universe

The universe is an implicitly declared feature that is the outer feature of all features that are not explicitly declared within another feature.

Universe Instance

The universe instance is an implicit singleton instance created by the implicit call to the universe on system startup.

Appendix B: File Formats

B.1. FUM — Fuzion Module File

Appendix C: BNF Grammar

The following shows the Grammar using a notation similar to Backus–Naur form [bnf].

link:{FUZION_EBNF}[role=include]

Bibliography

Index

LocalWords: Fuzion MERCHANTABILITY ASCIIdoc SRCF DOTFZ UTF LEXR LEGALCP fuzion LocalWords: UNUSEDCP whitespace IDENT OPER