We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Fuzion Language Update

00:00

Formal Metadata

Title
Fuzion Language Update
Subtitle
The marathon run
Title of Series
Number of Parts
287
Author
Contributors
License
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
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. This talk will present the advances in the Fuzion languages since its first public announcement at FOSDEM 2021. This includes a simplified and cleaned-up syntax, improved type inference, its safety features, foreign language interface to Java and an overview of the existing and planned toolchain. Fuzion is not only about the language itself, but just as well about the intermediate representation that is the basis for static analysis, optimization and back-ends. The talk will give an overview of the format of intermediate code.
Engineering drawing
PrototypeImplementationSoftwareTwitterEmailFluid staticsMathematical analysisJava appletCompilerTurbo-CodeVorwärtsfehlerkorrekturSPARCCompilerInterface (computing)Decision theoryInheritance (object-oriented programming)AerodynamicsSoftware developerTask (computing)Array data structureSpacetimeSystem callFlow separationStatement (computer science)Block (periodic table)Parameter (computer programming)Price indexElement (mathematics)Operator (mathematics)Parity (mathematics)Parameter (computer programming)SpacetimeDifferent (Kate Ryan album)Term (mathematics)Software developerSimilarity (geometry)Line (geometry)Inheritance (object-oriented programming)State of matterCASE <Informatik>Compilation albumMathematicsLevel (video gaming)Open setPoisson-KlammerSineAreaCore dumpSubject indexingContrast (vision)Operator (mathematics)Mixed realityProgramming languageBlock (periodic table)CodeStatement (computer science)System callSquare numberPrice indexElement (mathematics)PrototypeImplementationPhysical systemRow (database)Decision theoryFlow separationClosed setField (computer science)Arithmetic mean2 (number)Task (computing)Condition numberMereologyComa BerenicesPhysical lawConstructor (object-oriented programming)Multiplication signSocial classMedical imagingResultantObject-oriented programmingDatabase transactionPulse (signal processing)Error messageCurvatureJava appletChainSinc functionParsingDynamical systemTupleFunktionalanalysisComputer animation
Parameter (computer programming)Operator (mathematics)Java appletSpacetimeSoftwareCodeTypinferenzRegulärer Ausdruck <Textverarbeitung>String (computer science)IntegerSquare numberInferenceLambda calculusSystem callSquare numberParameter (computer programming)CASE <Informatik>Field (computer science)BitIntegerPoint (geometry)Operator (mathematics)ExpressionSoftware developerSpacetimeString (computer science)ResultantPropagatorSemantics (computer science)MathematicsDampingAdditionJava appletAreaWritingCasting (performing arts)Programming languageCodeRight angleInstance (computer science)Logical constantLambda calculusDirection (geometry)Default (computer science)TypinferenzSource codeMultiplication signRevision controlMultiplicationPrototypeMessage passingDifferent (Kate Ryan album)Power (physics)Data miningMetropolitan area networkFlow separationNumberCartesian coordinate systemCurveArmMixed realityLatent heatTowerComplex analysisMetreWordComputer animation
TypinferenzSoftwareBinary fileModule (mathematics)CodeRegulärer Ausdruck <Textverarbeitung>Source codeCoroutineAbstractionParameter (computer programming)Read-only memorySystem callLibrary (computing)Mathematical analysisJava appletInterface (computing)Physical systemServer (computing)Complete metric spaceAbelian categoryGeneric programmingProduct (business)FunktorIdentity managementCategory of beingTerm (mathematics)Standard deviationTelecommunicationThread (computing)Software developerFeedbackSource codeComputer fileBitDomain nameAxiom of choiceVideo gameInformationPersonal digital assistantParameter (computer programming)Point (geometry)Virtual machineStructural loadState of matterParsingLimit (category theory)Interface (computing)NumberMathematical analysisJava appletModule (mathematics)Process (computing)Compilation albumSoftware developerExecution unitSystem callFlow separationPhysical systemImplementationLibrary (computing)DebuggerExpressionCodeoutputSemiconductor memoryBinary codeCartesian coordinate systemSpeicherbereinigungMatching (graph theory)Front and back endsField (computer science)Abstract syntax treeText editorIntegrated development environmentProgramming languageElectronic signatureIntermediate languageComplete metric spaceMathematical optimizationBinary fileServer (computing)Endliche ModelltheorieDecision theoryContext awarenessMedical imagingOnline helpInterpreter (computing)WebsiteThread (computing)Keyboard shortcutForm (programming)FeedbackPreprocessorTelecommunicationSheaf (mathematics)Monad (category theory)Declarative programmingMoment (mathematics)Position operatorCoroutineProjective planeLink (knot theory)Network topologyAbstractionStandard deviationRow (database)Different (Kate Ryan album)Direction (geometry)PlanningMultiplication signSocial classArithmetic meanCurvatureReal numberLogical constantInformation securityTerm (mathematics)MetreCoefficient of determinationForestComputer animation
Element (mathematics)2 (number)Representation (politics)Data conversionField (computer science)Java appletFlow separationMultiplication signSpacetimeParameter (computer programming)Front and back endsRule of inferenceSource codeProgramming languageVapor barrierVector potentialCodeMoment (mathematics)Semantics (computer science)Video gameRight angleSequelInheritance (object-oriented programming)Numbering schemeAstrophysicsComputer animationMeeting/Interview
Engineering drawing
Computer animation
Transcript: English(auto-generated)
Hello and welcome to this update to the Fusion language I will give you an insight of a part of the long marathon run from the language prototype that I have presented on last for STEM to watch the full implementation and tool chain
This is some background on me I have lots of experience in compilers and languages, but I don't go into details here, but dive directly into the motivation. Why do we do a Fusion? Why a new language? I see that many languages are more and more overloaded with concepts like classes, methods, interfaces, constructors, traits, records and so on
while Fusion tries to simplify this significantly by providing only a single concept that of a Fusion feature Furthermore today's compilers and tools are much more powerful and they often make better decisions than the developers So why not let them take over these decisions? And today's systems are often safety critical
So we need languages that ensure the correctness of our systems Summary of the Fusion language It's based on the Fusion feature as its main concept. It is statically typed
It is object oriented. It has inheritance and redefinition It typically uses value types, but it also supports dynamic reference types It encourages immutability and it tries to offload as many tasks and decisions from the developers to the tools as possible
Since last year we have a Fusion logo now, so this is our language logo, and I think it shows quite nicely the concept of Fusion to unify different aspects of programming languages into one And also since last year, we have a new backing company to support the development of Fusion
Which is Tokiwa Software GmbH. We currently have three employees. We are hiring and we are also searching for long-term funding An update on the Fusion language a lot of work went into the syntax of the language to make it more clear and easier using white space. So the idea is to avoid things like semicolons or
curly braces parenthesis commas wherever possible and use white space instead to increase the clarity and readability and also to avoid errors And I'll go into examples here first
For semicolons Fusion uses the concept of flat line feed. A flat line feed is a line feed that doesn't change the indentation level of a statement and this the parser takes this as equivalent to a semicolon. So we don't need a semicolon in this case
Well, it's still possible to put several statements into a single line But now we need a separator between the statements so there we can still use a semicolon Next blocks are typically formed using curly braces
but as an alternative Fusion provides so-called indenting line fields line feeds which means if you have a new line that increases the indentation level the parser treats this exactly as an opening curly brace and
if the indentation level goes back to the previous that is treated as a closing curly brace so we can get rid of the curly brace in our code as long as the indentation is as you would usually do it anyway. Nevertheless you can still put several statements
into a single line but then you have to make sure that in like in this case for an if statement there is a keyword then separating the condition from the statement that the parser knows where the statements would start. Next calls. Calls classically use parenthesis and commas to
separate the arguments from the called function. Fusion is much more like Haskell here where just spaces are used to separate the called feature name from the arguments and the arguments from
one another. If you have nested calls you still need parenthesis though like here's an example where feature f is called with the result of a call to g and a call to h who themselves have arguments x y and z and this nesting is equivalent to what you would write like this
in a classic parenthesis calling syntax. It might be for somebody used to languages like Java this might look very confusing in the beginning but after you got used to that
this is actually a much clearer and easier to read syntax. One difficulty with this calling syntax though is when using calls in conjunction with tuples so if you have a call with two
arguments that could be read and written without spaces or with parenthesis if instead you have a call to a feature g and you pass a tuple consisting of a and b to that feature we have almost the same syntax here so the difference is just the space between the
called feature name and the opening parenthesis and this syntax difference is actually semantically very significant in Fusion. In this case we pass a tuple a and b as a single parameter to g while in the case without a space in between we call a feature with two arguments
a and b. Next area is array accesses. In Fusion an array access is done with square brackets
and here's an example of accessing an array a which is two-dimensional at indices i and j which would be written like this. Also Fusion has a syntax to create an array literal in this case here's an example to create an array consisting of the elements x y and z
you write it like this. Now if you pass such an array to a feature f you would write this like this f and then separate with a space the argument is the array of x y and z and here again we have a significant difference made just by the space
after the name of the called feature if it is there it's an array that we pass as an argument while if it's not there it is an index call
using square braces. Operators are another interesting area if we have a call and we pass minus x as an argument we can write this like that and this is equivalent like if the minus x
put in parentheses so the minus has precedence over the call if it sticks directly to the argument but in contrast to that if you have a separation with spaces between the operators and the argument this is parsed as an infix operator so f space minus x is the same as
subtract x from f if by contrast we have f minus space x this is parsed as a postfix operator
operating on f and the result used as the target of a call to x so in this case f has to f minus has to return a feature that can be called and that will be called then we're given the argument x next infix operators also we can pass an expression i minus b to
a called feature f and if there's no spaces then the value of a minus b is passed as the argument to feature f while if we put a space between behind a these are parsed as two different
arguments so f is called with two arguments a and minus b however if we completely separate the operator from both arguments then the binding of the call f to the argument is stronger
than the binding of the operator so this will be parsed as f applied to a single argument a and b being subtracted from the result so the important thing is that the binding of a call is stronger than an operator that is separated by white space while an operator
that is not separated by white space binds stronger than a call for those who might be surprised and shocked by the rigorous use of white space for semantics here please be aware
that also other languages like java where it's not so obvious you have important semantic changes depending on addition of white space which is shown with a small example here where introduction of a single white space completely changes the semantics our next area
I'd like to represent is type inference type inference is used to avoid the need to write explicit types in source code and type inference occurs in fusion whenever values are assigned
to fields to features this could be in an explicit assignment like here an expression is assigned to a field x or the result of a feature like here ga is the result of the feature call f that is assigned to the feature result and here in the third example we have
a literal that is assigned to the argument field of the code feature h and during type types actually propagate in two directions two possible directions one would be from the
expression to whatever they are assigned to but the other way could also occur where the target of an assignment propagates its type to the expression that is assigned to target and I bring examples of that shortly so here is a few examples of forward propagation
where a literal constant 123 is assigned to a field v and the type of that field is just the default type for integer constants which is i32 in fusion same for the next
where a string constant of type string is assigned to a new field s and the type of s is inferred from the constant so it is a true string next example shows where the result type of a feature h is inferred from the expression that
is returned as a result so in this case the type u8 of v is also the result type of v shifted to the right so the result of this feature is u8
this can also occur with more complex types like here we create an instance of point with two parameters zero and zero which is of type point i32 and that is the result type
of this origin feature type inference is also used for type arguments so the actual type arguments in a call are propagated from the arguments given to the actual call so we
have an example here where a feature square that has a type argument t that squares a value of an arbitrary integer type this square function can be called either with an
explicit type parameter where here we have square of i32 values called on 123 but this type argument can also be inferred automatically so we can leave it out since i32
is the default type of integer literals so we can skip this very important for the convenience of the developer is type propagation for lambdas and for lambdas
now the type propagation goes the other way around so from the target of the assignment types are propagated to a lambda expression so we have an example here of two features si and first receives a function argument that takes a string and an integer and produces a string
while the second takes two integers and produces an integer and if we call both of these features giving the same syntactically the same expression the types are propagated from
the target from what is called towards this lambda expression so in this first case the type would be a string and i32 to string so this will repeat the string i times
while the second version will have just integer types so this will perform an integer multiplication another example for backward type propagation are numeric literals so if we assign an integer constant to a field with an explicit type in this case unsigned 16
bits then the type of that field gets propagated to the literal and the literal has the type unsigned 16-bit value this also works if the literal value actually looks like a float
as long as it is representable as the target type the type of even this float looking constant is unsigned 16-bit and one specific case that looks a bit like a cast but it's
actually the same thing is if we call u16 here and pass as an argument the constant the uh feature u16 actually expects an argument which is exactly of the same type which is unsigned 16
so here the type gets propagated from the argument from u16 which is u16 to the constant so we also have a literal of type u16 in this case and a fairly nice syntax to produce
constants of a particular type the same holds if we use floating point 64 values for this we can declare a field of that type and in this case this constant will be a floating point value
also when we use the standard floating point syntax but also if we use the floating point call for f64 call for this constant so next i want to give you an overview over the fusion toolchain and the current state of the development here the toolchain starts with
fusion source code files and a front end produces processes these source code files to produce fusion module files and these module files are then
are taken as an input by a middle end to produce a fusion application file and this application file oops i have to move out of the way now that you can see this this application file is then taken by an optimizer to create an intermediate representation for you
which is then taken as the input by different back ends to produce something like binary code or jar files or whatever can be executed on your system now this is the planned design
the actual implementation that was presented at FOSTM last year takes a lot of shortcuts there was basically an interpreter that runs on top of a jvm and data from the front end like the abstract syntax tree and so on was formatted and used directly in the interpreter
there was a basic middle end but also direct accesses to the abstract syntax tree and starting from this state from one year ago what has been done meanwhile is that a simple form of the optimizer has been developed that provides not as a file but as an interface
the intermediate representation and this interface was then used to implement a c back end that creates binary code through the llvm c compiler and here at least for the c back
end we have a very nice and clean separation from the back end and the front end it all goes through this freer interface here then the module file definition has been done
it is not finished yet but at least for the base library we can create a pre-compiled module file that is then used by the middle end and we go back to my original position i would like to present to you the format of these module files quickly it's a binary file format
so it looks something like this but i don't want to go into the details of the bits in here but i want to explain your domain purpose it's you it's a binary format such that it can be f
mapped directly to memory that the tools can very quickly load and access these files without any parsing or pre-processing module files use offsets to reference one another not names so lookup is very fast very direct and module files contain basically
the feature declarations from that module the types that are used by those features expressions that contain the code that is executed and also they contain a copy of the source code features in module files come in five different variants there can be routines that is features
that have code fields which is features that can store a value that can be intrinsics that is features that the back end has to implement abstract features that don't have an implementation and choice features that provide a union type and the types come in two flavors either in
feature types which is features plus possible type arguments and pure type parameter types and the expressions are currently only have 10 different kinds and these are things like a
call or a match or a constant an assignment or a pop so it's a stack based machine with a very limited number of expressions to make the tools at the back end simpler the impact of using these module files is first we have a much faster compilation because
we can use the pre-compiled modules and we have a unit for module based correctness and correctness analysis we have a unit to define visibility so we can have features that are local to to a module and features that are exported and visible to other modules and we can
use our modules as containers to exchange library code other tools there is a new tool fzjava that takes java modules and converts them into fusion source source files that we can
call java code directly from fusion we have implemented a fusion language server such that ides and editors have fusion language support like auto completion signature
help documentation helps and so on we have a fusion doc tool and the result of that you can see on the flung website that extracts documentation from the standard library and makes it easily browsable so the next step for fusion is there should be more support for
the intermediate files the module files are only partly supported at the moment application and still need to be supported we want to have simple analysis tools working on top of these module
files to check things like field initialization or immune nutribility the c backend still needs a garbage collector so we can't really use this for longer running application it doesn't floats yet and also there's now no counterpart yet to the fc java tool
to interface c library code so that is urgently needed to interface with other code we need a lot of work on the standard library and related to that we need to have a decision how to model
io and thread communication in the context of image ability one idea that is presented in design section on flung.dev is the use of automatic monadic lifting but we still have to put a lot of thought into that how to best do that so coming to the end we are running really
a whole marathon here in the implementation of this language and tools but as a marathon runner i know we have not made the first 10 kilometers yet and so it's long before the real pain starts
we really need to grow our team we need to get developers on board and get their feedback and also we need to secure long-term funding for the project so please get involved if you find the links are here to get information to get contact me or to get the source code
and for those who have seen last year's call in this dev room you probably wonder what happened to ellie ellie actually started her professional life as an assistant doc and she's happily helping her new owner thank you goodbye hi hi i have two minutes to quickly react to your questions
thank you first for your interest and for all the questions you pose the first hisham hm asked
when you say equivalent to does this mean the other syntax is still accepted talking about the syntax using parenthesis or spaces to separate arguments and curly braces and they are both accepted at the moment and i think i will keep that and i see that many potential users of
such language in particular with the java or c background are really reluctant to switch over to a space and indentation based schema so i don't want to put any extra barriers to those to switching over to such a language and i would like actually best to have tools
to automatically convert source code between the two representations just to to mute any arguments that say that there is too much semantics into in the white space and then the next question did you find it difficult to avoid generating c code that
exhibits undefined behavior not really but i was working on c backends for a long time so i'm kind of automatically avoiding those and next question from floyd hendrickson flatline field rule reminds him of the haskell's
offside rule i actually don't have much experience with haskell that doesn't haven't really used that uh so it's quite likely that they use something very similar uh for uh
uh replacing curly braces like what i did in fusion okay my time is up please contact me directly bye-bye