Fuzion Logo
fuzion-lang.dev — The Fuzion Language Portal
JavaScript seems to be disabled. Functionality is limited.
Fuzion • Mission Statement

Mission Statement

The Programming Language

The Fuzion programming language shall define powerful features that join the capabilities of features of existing languages. Implementation details such as where to store or how to layout data or whether to use early or late binding should be not be a concern for the developer, but for the Fuzion implementation and run-time system.

The Fuzion programming language should provide powerful capabilities found in popular programming languages including

  1. effects, to track an manage side effects
  2. objects, inheritance, dynamic binding
  3. algebraic data types (tuples and choices)
  4. encapsulation
  5. constrained generics
  6. design-by-contract
  7. immutable by default, mutability via effects
  8. concurrency and safety
  9. values and references
  10. first-class functions and closures
  11. statically typed
  12. tail call optimization
  13. eagerly evaluated, (lazy by choice)
  14. automatic memory management (GC)
  15. foreign function interface

The language should be concise but not cryptic. Verbose boilerplate code should be avoided, data inferred by the compiler should be preferred over date provided by the developer. Syntactic sugar should be used carefully to achieve conciseness and clarity.

Language features that can be implemented as part of the standard library should preferably be provided as part of the standard library and not as part of the language. E.g., basic types like integers and operations on these such as infix + should be part of the standard library and not part of the language.

Fuzion does not exist in a void, there are many existing powerful languages such as Java, Scala, Python, C, C++, Kotlin, Groovy, Clojure, Eiffel, and many more. The languages definition should feel free to steal and adapt ideas from all of these languages. However, the basic features of Fuzion shall be simple and powerful. If possible, concepts taken from these languages should not add to the complexity of the Fuzion language but instead either be added and implemented within the standard library or added as syntactic sugar that maps to existing mechanisms within Fuzion.

Intermediate Code

Fuzion source code should be compiled into a platform-independent code similar to the way Java is compiled to Java Byte Code. There are several advantages of using such an intermediate code instead of using the source-code directly or creating machine code:

  • the source code is analyzed for correctness
  • complex syntax in the source code is handled by the source code compiler
  • the run-time system(s) or language tools can operate on the simpler intermediate code instead of having to parse the more complex syntax of the source code
  • compared to machine code, the intermediate code provides a binary format that is platform independent

Disadvantages of using an intermediate code also exist, in particular

  • the intermediate code will not help to obfuscate the source code, reverse-engineering is typically easy
  • the intermediate code requires one additional compilation step
  • a command line interpreter becomes harder to implement because of this additional compilation step

Design Decisions

Granularity of files

The granularity of files has an important impact on efficiency and usefulness

  • one file per class, as in Java, causes a lot of redundancy due to the same constants and names appearing in different files
  • zip archives are an ugly hack to remove this redundancy
  • Some definition of a “module” to contain a set of classes is needed
Visibility

It needs to be decided to what extend the contents of one file are “closed” with respect to other files or open for access or even addition of other classes. What is exported from one module?

Dependencies and Versioning

Modules may depend on other modules, these dependencies should be expressed clearly. Dependencies might request specific versions of other modules.

Modules may exist in different versions and dependencies might require newer or older version, such that it might make sense at run-time to load different version of the same module within one run-time instance.

It needs to be decided if circular dependencies are needed and should be allowed or forbidden.

Code

Basic decision between stack and register machine is required.

Run-time Systems

Possible choices for run-time system

  • On top of OpenJDK/OpenJ9/etc.
  • Using Graal for compilation
  • Using Truffle/Graal/SubstrateVM
  • Using LLVM
  • Creating stand-alone binaries, compiling to C or plugging into existing Code generator (LLVM, OMR, etc.), what GC?

Standard Library

Core library

Optional modules

It will be paramount for the success of Fuzion to provide easy access to cool features, such as

  • Computer vision, image classification, such as OpenCV, TensorFlow, etc.
  • Natural language processing (à la Siri, Alexa, etc.)
  • 3-D graphics (OpenGL etc.)
  • Video players, codecs
  • GUI, e.g. WxWidgets
  • modern user interfaces, gestures, etc.
  • web server
  • command line interface
  • relational database interface
  • json

Interoperability

  • SWIG support
  • direct Java interface
  • direct C/C++ interface

Testing Tools

  • JUnit
  • pytest

Fuzion Development Tools

Fuzion Marketing

Fuzion Website

Fuzion Libraries/Modules Server

GIT-Hub repo

Conferences

Conferences that join the developer community