Fuzion Logo
flang.dev — The Fuzion Language Portal
JavaScript seems to be disabled. Functionality is limited.

Fuzion Declaration Syntax

Declarations for features may require type information if the type cannot be derived automatically by the compiler. The basic distinction here is whether the type should be before or after the declared feature.

Mixing type and declared entity

The C/C++ programming language chose to mix the types and the declared entity, e.g.,

C/C++
  int a[3];
  int (*f)(int);

Such confusing syntax must be avoided, this is extremely hard to parse for humans.

Type before declared entity

Java (with exceptions)
  int[] a;
  java.util.Vector v;

Type after declared entity

Rust Modula-2 Go
  let y: f32 = 3.0; // f32
VAR Count : INTEGER;
    x,y   : INTEGER;
x int
p *int
a [3]int
f func(func(int,int) int, int) func(int, int) int

Separating type and declared entity

Using an explicit separator like ':' between the type and the declared entity makes parsing the language significantly simpler, but it adds code.

References

Go uses entity name before type without separator symbol, there is a nice blogpost giving the rationale: Go declaration syntax rationale.

Separation of argument list and result type

Other languages

Here are some example how languages separate the result type (rt) from the argument list (here for one argument x of type at) in a function declaration:

Haskell Java Rust Pascal
f :: at -> rt
f x = ...
      
rt f(at x) { .. }
      
fn f(x: at) -> rt { .. }
      
function f(x : at) : rt;
begin
  ...
      

Fuzion

Fuzion requires formal arguments to be enclosed in parentheses ( ), the result type follows immediately after the argument list:

Fuzion using explicit result type Fuzion using result type inference
f(x at) rt is ...
      
f(x at) => ...
      

Fuzion type syntax and argument list syntax are similar such that some types can be parsed as valid argument lists and vice versa. This is a problem for Fuzion features with an empty argument list that return a result of type tuple:

Fuzion code interpretation
f (a, b i32) is ...
      
constructor with two arguments of type i32 returning a new instance of f.
f (a, b i32) unit is ...
      
function with two arguments of type i32 returning a unit value (i.e. nothing).
f () (a, b i32) is ...
        
function without arguments returning a tuple of types a and b i32 using explicit result type
f => (a x y, b i32 z)
        
function without arguments returning a tuple of types a and b i32 using type inference
f (a, b i32) -> bool is ...
        
function without arguments returning a function taking to arguments of types a and b i32 and resulting in bool.

Fuzion using =>

We could introduce => as a required separator between the argument list and the result type. This would turn these examples into the following:

Fuzion using explicit result type Fuzion using result type inference
f(x at) => rt is ...
      
f(x at) => ...
      

Examples of disambiguation of tuple result and argument lists using =>:

Fuzion code interpretation
f (a, b i32) is ...
      
constructor with two arguments of type i32 returning a new instance of f.
f (a, b i32) => unit is ...
      
function with two arguments of type i32 returning a unit value (i.e. nothing).
f () => (a, b i32) is ...
        
function without arguments returning a tuple of types a and b i32 using explicit result type
f => (a, b i32) is ...
        
function without arguments returning a tuple of types a and b i32 using explicit result type
f => (a x y, b i32 z)
        
function without arguments returning a tuple of types a and b i32 using type inference
f => (a, b i32) -> bool is ...
        
function without arguments returning a function taking to arguments of types a and b i32 and resulting in bool.

We need to decide if a clear separator like => between argument lists and result type brings an advantage.

Pros:

Cons:

A third alternative would be to add => as an optional separator. This, however, will very likely introduce confusion since it will be required (and hence used) in very few, specific cases (when a function's result is a tuple).