Fuzion Language Update

Introduction Fuzion is a modern general purpose programming language that unifies concepts found in structured, functional and object-oriented programming languages into the concept of a Fuzion feature. It combines a powerful syntax and safety features based on the design-by-contract principle with a simple intermediate representation that enables powerful optimizing compilers and static analysis tools to verify correctness aspects. Fuzion was influenced by many other languages including Java, Python, Eiffel, Rust, Go, Lua, Kotlin, C#, F#, Nim, Julia, Clojure, C/C++, and many more. The goal of Fuzion is to define a language that has the expressive power present in these languages and allow high-performance implementations and powerful analysis tools. Furthermore, Fuzion addresses requirements for safety-critical applications by adding support for contracts that enable formal specification and enable detailed control over run-time checks. Many current programming language are getting more and more overloaded with new concepts and syntax to solve particular development or performance issues. Languages like Java/C# provide classes, interfaces, methods, packages, anonymous inner classes, local variables, fields, closures, etc. And these languages are currently further extended by the introductions of records/structs, value types, etc. The possibility of nesting these different concepts results in complexity for the developer and the tools (compilers, VMs) that process and execute the code. For example, the possibility to access a local variable as part of the closure of a lambda expression may result in the compiler allocating heap space to hold the contents of that local variable. Hence, the developer has lost control over the allocation decisions made by the compiler. In Fuzion, the concepts of classes, interfaces, methods, packages, fields and local variables are unified in the concept of a Fuzion feature. The decision where to allocate the memory associated with a feature (on the heap, the stack or in a register) is left to the compiler just as well as the decision if dynamic type information is needed. The developer is left with the single concept of a feature, the language implementation takes care of all the rest. Fuzion Feature Declarations A Fuzion feature has a name, similar to the name of a class or a function. The main operation that can be performed on a feature is a feature call. The constituents of a feature declaration are as follows: Formal Arguments Features may have a list of formal arguments, which are themselves features implemented as fields. On a call to a feature with formal arguments, actual arguments have to be provided to the call, unless the list of formal arguments is empty. Feature Result The result of a feature call is an instance of the feature. Alternatively, a feature may declare a different result type, then it must return a value of that type on a call. Closures Features are nested, i.e., every feature is declared within the context of an outer feature. The only exception is the universe, which is the outermost feature in Fuzion. A feature can access features declared in its outer feature or, recursively, any outer feature of these outer features. This means, a feature declaration also defines a closure of the feature and its context. When calling a feature f1 declared as an inner feature of f2, the call must include a target value which is the result of a call to f2, e.g., f2.f1. Generics Features may have generic type parameters. E.g. a feature declaration may leave the actual type used within that feature open and to be defined by the user of the feature. The list of generic type parameters may be open, i.e., the number of actual generic type parameters is not fixed at feature declaration. This turns out to be useful in the declaration of choice types and functions as explained below. Inheritance Fuzion features can inherit from one or several other features. When inheriting from an existing features, all inner features of the parent automatically become inner features of the heir feature. It is possible to redefine inherited features. In particular, when inheriting from a feature with abstract inner features, one can implement the inherited abstract features. A redefinition of an inherited feature may implement an inherited feature as a routine or as a field. An inherited feature that is implemented as a field, however, cannot be redefined as something else since fields might be mutable. Inheritance may result in conflicts. An example would be two features with the same name that are inherited from two different parents. In this case, the heir must resolve the conflict either by redefining the inherited features and providing a new implementation or by renaming the inherited features resulting in two inner features in the heir feature. Inheritance and redefinition in Fuzion does not require dynamic binding. By default, the types defined by features are value types and no run-time overhead for dynamic binding is imposed by inheritance. A Contract A feature may declare a contract that specifies what the features does and under which conditions the feature may be called. An implementation Features must have one of the following implementations a routine is a feature implementation with code that is executed on a call a field is a memory slot that stores a value and whose contents are returned on a call an abstract feature has no implementation and cannot be called directly, but can be implemented by heir features an intrinsic feature is a low-level feature implemented by the compiler or run-time system, e.g., the infix + operator to add two 32-bit integer values may be an intrinsic operation. A feature implemented as a routine can contain inner feature declarations. Feature examples Here is an example that declares a feature point that functions similar to a struct or record in other languages: point(x, y i32) is # empty p1 := point 3 4 say "p1.x is {p1.x}" # will print "p1.x is 3" say "p1.y is {p1.y}" # will print "p1.y is 4" The next example shows a feature base that provides an inner feature plus that adds its argument to the value passed to the enclosing base: base(v i32) is plus(w i32) => v + w b1 := base 30 b2 := base 100 say (b1.plus 23) # will print "53" say (b2.plus 23) # will print "123" Fuzion Syntax Evolution Fuzion provides two main syntax alternatives, a classic once using semicolons, braces and parentheses and a modern one using white-space and indentation. Both are equivalent, there should be tools between these two representations of source code. The following explains the main ideas how white-space is used instead of special symbols Separating Statements Flat line feeds instead of semicolons The classic way to separate statements is by using a semicolon as in stmt1; stmt2; stmt3 or stmt1; stmt2; stmt3; The Fuzion grammar knows a symbol called 'flat line feed', which is a line feed with the next line starting with white space up to the previous line's indentation level. A 'flat line feed' is considered equivalent to a semicolon, so the sequence of three statements above can be written without semicolons as follows: stmt1 stmt2 stmt3 Indenting line feeds to form blocks Code blocks in Fuzion can be build using braces similar to many other languages if cond { stmnt1 } else { stmnt2 } if cond { stmnt1 } else { stmnt2 } if cond { stmnt1 } else { stmnt2 } An 'indenting line feed' in Fuzion is a line feed with the next line starting at a higher indentation level. The parser treats an 'indenting line feed' like a left brace '{'. Correspondingly, a linefeed that reduces the indentation level back to the original level is treated like a right brace '}'. The example above is hence equivalent to if cond stmnt1 else stmnt2 Finally, an optional keyword 'then' may as well be used to separate an expression like the condition in an 'if' from a following expression without the need of braces: if cond then stmnt1 else stmnt2 Separating calls, arguments and operator expressions calls without parentheses Fuzion calls do not need parentheses or commas to separate the called feature and its arguments, i.e., a call f(a, b, c) can be written as f a b c Parameters are then separated by white space. Line breaks, either flat or indenting as explained above, end the argument list. Parentheses may be needed for nesting calls with arguments, e.g., the code f (g x y) (h z) is equivalent to f(g(x, y), h(z)) If placed in parentheses, operator expressions may extend over several lines using an indenting line feed followed by additional flat line feeds, e.g., f (1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 + 11 + 12) Tuples of values such as '(a, b)' syntactically look like argument lists. A list of expressions enclosed in parentheses is treated as an argument list only if it immediately follows the name of a called feature. The code f(a, b) hence calls 'f' with two arguments 'a' and 'b'. In case there is white space after the name of the called feature as in f (a, b) the expression in parentheses is passed as an argument, so, in this case 'f' will be called with a single argument: the tuple '(a, b)'. Array indexing vs. array creation The square brackets '[' and ’]’ are used in Fuzion for two purposes: A pre-initialized array of fixed size can be created using an expression like '[x, y, z]', while an array can be indexed using 'a[i]'. Again, white space can be used to distinguish these two cases: a[i] read an element from an array while f [x, y, z] create array with elements x, y and z and passes it as an argument in a call to 'f'. Operator expressions Operators are parsed as prefix- or postfix operators if the are not separated by white space from their target operand, but they are separated by white space on the other side. This means that the call f -x is equivalent to f (-x) while f - x f-x both subtract 'x' from 'f'. Furthermore, f- x is parsed as (f-) x i.e., it calls 'postfix -' on 'f' and, assuming the result is a function, calls this result with one argument 'x'. The precedence of operators that are not separated by white space is stronger than that of a call, so f a-b is equivalent to f (a-b) while the precedence of calls is higher than that of operators separated by white space, i.e, f a -b f a - b are equivalent to f (a) (-b) (f a) - b respectively. White space vs. explicit tokens Attaching semantics to white space might appear dangerous and error-prone to those not used to it. However, more and more languages (Python, Scala-3, Nim, Raku, ...) make use of white-space and the experience is generally very positive, the code is cleaner, easier to read an even easier to maintain. Compiler errors complaining about unbalanced parentheses or braces are gone and mismatch between indentation and semantics may no longer occur. Furthermore, even languages like Java allow code to have hugely different semantics if just a single white space is added, e.g., the Java code if (cc) x(); elsey(); if (cc) x(); else y(); changes completely by insertion of a single space character. Fuzion Type Inference Fuzion is statically typed, every expression, every field, every routine result has a static type known at compile time. Type inference is used to avoid the need to specify these types explicitly in many situations, reducing the boilerplate code while keeping the safety of a statically types language. Type inference in Fuzion occurs at explicit or implicit assignments. An explicit assignment is a field declaration with an initial value such as v := expr while an implicit assignment occurs, e.g., when a routine returns the value of its last expression as its result sum (x, y u32) => x + y or when an argument is passed to a function sum 1.234e6 567890 Type inference occurs in two directions: From the value to the field that the value is assigned to and from the type of the assigned field to the value. Field declarations using ':=' without an explicit type use the type inferred from the value, the same holds for routines defined using '=>'. On the other hand, the type of expressions such as lambdas or numeric literals are inferred from what they are assigned to. Type inference from expressions to feature result type When declaring either a field using ':=' or a routine using '=>', the result type is inferred from the expression that is assigned or returned, respectively: v := 123 # type i32, default type for integer literal v := "hello" # type string highNibble(b u8) => b >> 4 # type u8 origin => point 0 0 # type point Type inference from expressions to type arguments Type arguments are inferred from actual arguments as shown by the following example: Imagine a generic routine square as follows square<T: integer<T>> (a T) => a * a This could be called using explicit type arguments as in say (square<i32> 23) or the type can be inferred from the argument type say (square 23) As a consequence, type arguments can be omitted in many cases. Type inference for lambdas In Fuzion, inline functions (lambdas) are defined using '->' with the input variables on the left and the expression on the right. Types for a lambda are implicitly taken from the target the lambda is assigned to. E.g., the following example takes a function argument print(s string, f (string, i32) -> string) => say (f s 3) print(f (i32, i32) -> i32) => say (f 10 3) print "Alice" (s,i -> s * i) # lambda type is (string, i32) -> string print "Bob" (s,i -> s + i) print (s,i -> s * i) # lambda type is (i32, i32) -> i32 print (s,i -> s + i) Type inference for numeric constants Numeric constants that are assigned to a given type inherit that type. There is no immediate distinction between plain numeric literals like '123' or ones using a fractional parts and exponents such as '-0.1234E4'. The target type determines the type of the constant. v1 u32 := 123456 v2 i8 := -128 v3 i16 := 32000 v4 u64 := 1000000000000000000 v5 i64 := -1000000000000000000 v6 u16 := 4711 v7 f32 := 123456 v8 f64 := 123.456E6 v9 f64 := 1.0E3 In case the constant is too large for the target type, or it has a fractional part not representable by the type, a compile-time error occurs: v1 u32 := -123456 # error: negative value assigned to unsigned v2 i32 := 3000000000 # error: value too large v3 i8 := 128 # error: value too large v4 u16 := 65536 # error: value too large v5 f32 := 123.456E39 # error: overflow v7 f64 := 123.456E309 # error: overflow v8 f32 := 7E-46 # error: underflow Fuzion Intermediate Files Fuzion uses intermediate files during different stages of compilation: module files that contain library code, application files for whole applications and Fuzion intermediate representation files that serve as input to the back ends. Fuzion uses a simple intermediate code to represent pre-compiled modules and whole applications. This intermediate code serves as the input for static analysis tools, optimizers and for different back-ends that produce executable applications. The goal in the design of the intermediate file format was high performance and simplicity for tools using this code. The intermediate code is a binary format containing features and types in a way that may be mapped to memory and used directly, so overhead of parsing this format into an in-memory representation is avoided. In particular, if only parts of a pre-compiled module are used by an application, there is no need to read and unpack parts of the module intermediate representation that are not used. For features containing code, a very simple stack-based format is used. There are currently only ten different instructions: Unit -- produce a value of unit type Current -- produce the current instance as a value Constant -- produce a constant value Assign -- perform an assignment to a field Call -- perform a call to a given feature Tag -- convert a value into a tagged value of a choice type Match -- match a choice type Box -- convert a value type to a ref type Unbox -- extract the value from a ref type Pop -- drop the top element from the stack The intermediate code uses indices to refer to features and types within intermediate files. This means that lookup is very efficient, but it also means that a change in a library module requires recompilation of all dependent modules. Any incompatibilities would be found at compile time instead of resulting in something like Java's 'IncompatibleClassChangeError' at run-time. Foreign language interface Fuzion provides a tool 'fzjava' that takes a Java module file and converts it into Fuzion features. In the spirit of Fuzion, Java's packages, classes, interfaces, methods, constructors, static methods and fields are all converted into Fuzion features. Java methods that may throw an exception are converted into features resulting in a choice type that is either the exception type or the result type of that method. A few intrinsic functions in the Java interpreter back-end use Java's reflection API to access the corresponding Java code. Here is a example how Java code can be used from Fuzion: javaString := java.lang.String.new "Hello Java 🌍!" # create Java string, type Java.java.lang.String javaBytes := javaString.getBytes "UTF8" # get its UTF8 bytes, type is fuzion.java.Array<i8> match javaBytes err error => say "got an error: $err" bytes fuzion.java.Array => say "string has {bytes.count} bytes: $bytes" javaString2 := java.lang.String.new bytes 6 bytes.count-6 # create Java string from bytes subset, say "Hello "+javaString2 # append Java string to Fuzion string and print it C back-end Fuzion now has a back-end that produces C source code to be compiled to machine code using clang and LLVM. Fuzion safety A main goal of Fuzion is to provide a development tool for safety-critical applications. Fuzion brings a number of features that address safety issues at different levels: Language features static typing language simplicity pre- and post-conditions for design by contract no wrap-around for standard operations +, -, *, /, etc. mutability restricted to local contexts Run-time features dynamic checks where static checks are not sufficient (real-time) garbage collection Environment features static linking to specific library versions static analysis tools no dynamic code loading simple intermediate representation, simpler tools Conclusion and Next Steps The Fuzion language definition and implementation are far from stable, but are getting closer to become useful. Big improvements come from the ability to pre-compile modules and from the foreign language interface for Java, which makes a giant code base accessible for Fuzion applications to build on. Additionally, new projects such as the language server implementation for Fuzion by Michael Lill help by integrating Fuzion support in popular IDEs and editors. Main points that are missing right now are a powerful standard library additional library modules for all sorts of application needs low-level foreign language interface for C actual implementations of static analyzers and optimizers highly optimizing back-ends garbage collection for the C back-end documentation, tutorials enthusiastic contributors and users! Please feel free to contact me in case you want to use Fuzion or want to help making it a success!