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
- objects, inheritance, dynamic binding
- algebraic types (tuples and choices)
- constrained generics
- variables with immutable and mutable state
- concurrency and safety
- values and references
- first-class functions and closures
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.
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
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
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.
Basic decision between stack and register machine is required.
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?
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
- SWIG support
- direct Java interface
- direct C/C++ interface
Fuzion Development Tools
Fuzion Libraries/Modules Server
Conferences that join the developer community
- ACM SIGPLAN conferences: PLDI, ECOOP, etc.
- more conferences here: SW Engineering conferences 2020