Fuzion — Intro for Java Developers: Mapping Java's Features to Simpler Mechanisms
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
Title |
| |
Title of Series | ||
Number of Parts | 542 | |
Author | ||
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 | 10.5446/61520 (DOI) | |
Publisher | ||
Release Date | ||
Language |
Content Metadata
Subject Area | ||
Genre | ||
Abstract |
|
00:00
Java appletSoftwareMechanism designSoftware developerSPARCVorwärtsfehlerkorrekturTurbo-CodeCompilerTwitterFluid staticsMathematical analysisEmailSource codeFunctional programmingComputer programmingCompilerSystem programmingConstructor (object-oriented programming)Interface (computing)Social classProgramming languageDecision theorySound effectAlgebraic numberFormal languageEquivalence relationDemo (music)String (computer science)Computer virusPhysical systemOvalUniverse (mathematics)Reflection (mathematics)AerodynamicsMacro (computer science)CodePointer (computer programming)Control flowException handlingFormal languageMathematical optimizationExtension (kinesiology)CompilerSound effectCompilation albumConstructor (object-oriented programming)Interface (computing)Computer programJava appletCodeOvalType theoryMobile appVariable (mathematics)Exception handlingBitProjective planeMappingData managementPhysical systemParameter (computer programming)Process (computing)Perspective (visual)Functional programmingSpeicherbereinigungNumberInheritance (object-oriented programming)Social classGroup actionPoint (geometry)Macro (computer science)Integrated development environmentResultantDirection (geometry)Row (database)1 (number)Programming languageCASE <Informatik>Value-added networkFerry CorstenContrast (vision)Level (video gaming)Single-precision floating-point formatExecution unitSign (mathematics)WebsitePRINCE2Software developerCartesian coordinate systemUniverse (mathematics)Library (computing)MechatronicsMultiplication signMereologyReflection (mathematics)Field (computer science)Real-time operating systemSlide ruleSystem callDeclarative programmingRevision controlStandard deviationLetterpress printingEquivalence relationDemo (music)Mathematical analysisPointer (computer programming)Instance (computer science)Computer virusFluid staticsComputer animation
07:42
Java appletSoftware developerSound effectInformation securityGastropod shellSpring (hydrology)RWE DeaDecimalCodeMilitary operationAlgebraic numberFunctional programmingOperations researchException handlingInstallation artField (computer science)Information securityProcess (computing)System callInternetworkingFunctional programmingCalculationAllgemeine AlgebraStandard deviationSound effectBuildingInstance (computer science)Operator (mathematics)Variable (mathematics)Type theoryArithmetic meanException handlingError messageLibrary (computing)Programming languagePRINCE2Electronic signatureIntegrated development environmentImplementationField (computer science)CodeOptical disc driveView (database)Formal languageInterpreter (computing)Hydraulic jumpDrag (physics)Sign (mathematics)Multiplication signBitExpressionPoisson-KlammerProjective planeMarginal distributionSpherical capDifferent (Kate Ryan album)Java appletWebsiteSoftware developerWordLetterpress printingSet (mathematics)Connected spaceReading (process)Universelle AlgebraData managementComputer animation
15:18
Field (computer science)Software developerJava appletWebsiteDemo (music)SoftwarePrice indexLoop (music)Variable (mathematics)IterationInstance (computer science)Error messageAxiom of choiceDivision (mathematics)Formal languageLibrary (computing)ImplementationMathematical analysisFunctional programmingSound effectPosition operatorDifferent (Kate Ryan album)Source codeError messageField (computer science)Arrow of timeCASE <Informatik>ResultantSound effectInstance (computer science)DivisorIterationCodeWhiteboardLoop (music)Integrated development environmentIntegerSubject indexingVariable (mathematics)Exception handlingLibrary (computing)Inheritance (object-oriented programming)Type theorySystem callAxiom of choiceFunctional programmingDivision (mathematics)Matching (graph theory)Formal languageArmCartesian coordinate systemPRINCE2BitStandard deviationPreconditionerNetwork topologyProcess (computing)Thermal expansionMultiplication signOperator (mathematics)Function (mathematics)CountingView (database)Drag (physics)Default (computer science)Computer clusterState of matterSlide ruleMappingOcean currentImplementationSoftware developerVideo gameEndliche ModelltheorieMessage passingCompilerJava appletMathematical analysisExterior algebraIntermediate value theoremStandard errorFluid staticsParameter (computer programming)Lambda calculusInstallation artUniverselle AlgebraSemiconductor memoryRun time (program lifecycle phase)Direction (geometry)Module (mathematics)Stability theoryComputer animation
25:23
Object-oriented programmingConfiguration spaceGoodness of fitLetterpress printingSound effectIntegrated development environmentForcing (mathematics)Functional programmingCodeComputer animation
25:56
BuildingSound effect
26:47
Program flowchart
Transcript: English(auto-generated)
00:07
A really cool interesting project, a new language being presented by Pritcheoff called Fusion on the OpenJDK. Final session of the day. Thank you so much for being with us, some of you all day.
00:23
So let's start with Fusion or end with Fusion. Okay. Thank you for staying so long. Thank you for Gerd Schanz. He just downloaded the latest version of my slide deck and was a bit shocked that it's almost 100 slides and I only have 20 minutes left. So let's see how that will work out. For those who came for the Fusion stickers, please pass them around and take one.
00:49
So Fusion, a new language, and it's different. It's more from a Java perspective, but there's some overlap. You will see.
01:02
So basically the idea, the original idea of Fusion was to have something like a simpler Java, to simplify Java's feature, features into Fusion features. A bit of my background, I did work on compilers for about 30 years, a big part of that, working on real-time Java implementations, real-time garbage collection and so on.
01:25
Start with a motivating quote from John Bacchus, the inventor of Fortran, who said, who worked a lot on functional programming but was very disappointed because his work on functional programming basically failed and would likely always fail because functional
01:44
programming is easy to do hard things but incredibly difficult to do simple things. Fusion has evolved into a functional language and I think, I hope I find ways to even make the easy things easy with that.
02:00
So the motivation of Fusion is we see that languages like Java get more and more things packed in there. We already have classes, methods, interfaces, constructors, traits in other languages, records, structs, packages and so on. In Fusion, all of these map to one single concept, which is the concept of a Fusion feature.
02:21
And then I see today's compilers are much more powerful, so actually to distinguish whether some feature is more used like a method or like a class or like a constructor is something that the compiler decides then, it's not needed that the developer decides that. And we see that more and more systems are becoming safety critical, so we need to ensure
02:44
more correctness and I see that tools have to play in a very important role in ensuring this correctness by static analysis. Fusion is available on GitHub. There's a website flang.dev that gives an introduction into the language with lots
03:03
of examples, lots of design documents, lots of ideas collections. Please go through that. I can't give a language introduction here, but yeah, you'll find more there. Fusion is backed by a small company, Tokiwa, with currently four employees.
03:21
One of them is sitting here with us in the group, Michael. Now coming actually to this talk. So I will start with a very quick introduction into what the Fusion language looks like from a Java perspective, then talk a bit about side effects and their dangers, then propose
03:42
algebraic effects as a solution to manage side effects and give lots of code examples how you could do these things in Fusion. So here, a small example in Fusion, I will give a Java equivalent on the right side
04:01
and the Fusion code on the left side that you can quickly understand what it's about. So I said Fusion maps Java features to Fusion features. So in Java, if you have a package in Fusion, it's just a Fusion feature, in this case demo. If you have a class in Java, it is also a Fusion feature that is nested in another
04:23
Fusion feature. If you have a method in Java, it is again a Fusion feature that is nested in this case in the hello surrounding feature. In this case, what makes this feature different is that it's a function that returns
04:42
a result, which you can see from the result type here, which is unit. Unit type in Fusion is pretty much what the void type is in Java, but with the exception that it is a real type. So you can declare variables of type unit, you can return this as a value.
05:01
It is not a very interesting value, but you can have this as a full-fetch type with only one single value. In contrast to that, void is also a type in Fusion, but that gets interesting again because void is a type that has no values. So basically the result type of something like system exit in Fusion would be void,
05:25
which means it will never return. Then yeah, printing something is easy, there's a standard library function say that in this case prints hello world. Fusion uses a lot of type inferencing, so the result type unit here actually can be
05:46
inferred because that's also the result type of say, so we don't need to explicitly note this. Then I'll go back here. Very similar to Java, if you have code like that, you don't have anything to run yet.
06:03
You need in Java, you need some main function. In Fusion, there is one feature, which is called the universe, which surrounds everything and code put in the universe like here gets executed if you run your application. You can pass arguments to features and arguments are fields within those features and fields
06:27
are also features, so they come in the same class, but features that are pre-calculated that hold a value. Fusion has inheritance, so you can define a feature hello to that inherits from hello.
06:43
You can create an instance of that and call features on that. So that much to quick introduction into the language syntax and how it works. There's a number of things that Fusion does not have and mostly because these are things
07:05
that are considered to a certain extent harmful in a safe to critical environment. There's no dynamic loading. There's nothing like macros, no reflection, no pointer arithmetic. Many of these things also Java doesn't have. There is no uncontrolled mutability, so you cannot easily change variables.
07:25
There is no direct support for exceptions in the language and the reason for this is we must know what the code does. We want to do static analysis of the code to ensure safety and also to a certain extent to allow better optimizations to increase the performance.
07:46
So a bit more on side effects and security, we heard a lot about learned a lot about today already in earlier talks but mostly addressing security aspects of the software development process and managing of security issues.
08:05
I now come from the language side and say what we could do from the programming language to improve the security. If you look back at recent securities, we learned about log4j today, but there are similar
08:22
things to Spring Shell, even the Rust community has similar issues. What these things have in common, what these issues have in common is that code, library code that is used has unexpected side effects. So you use a logging library, you don't expect this to go to the internet and make
08:40
an arbitrary connection and download code from somewhere else in the world. So that is the common problem. So one way that is used by many new upcoming language to control side effects is to use algebraic effects.
09:01
So let me quickly explain to you what algebraic effect is. Algebraic effect is basically a set of non-functional operations that code might perform. So operations that do not have an effect on the actual calculation on the return value
09:22
of a function. Java already has one kind of algebraic effect built into the language which is throws for methods that throw exceptions. But algebraic effect is a more broader concept.
09:45
This is just one example that Java supports. Any operation in an algebraic effect can either resume or abort. So typically, if an algebraic effect is reading some data from some external input,
10:03
it would return the read data and resume operation with the value that was read. While an operation that would be something like throw an exception would perform an abort, so it will not return but jump back to the corresponding handler.
10:23
And algebraic effects can be implemented by different implementations of the effect handlers. So there's no strict fixed wiring from the operations to a particular implementation.
10:42
And very similar to exception handlers, effects may be nested. There's a kind of contrary view towards algebraic effects. As you can see, algebraic effects, what I've presented so far is as the effects that the
11:05
code might have, but you could also see them as capabilities that the code might require. Martin Odelski is starting a big research project in that area. What I do is I define my exception which is our exception implementation as a feature
11:56
inherited from the base library feature simple effect, which is just a basic standard effect.
12:02
And our implementation of throw is just abort. So the simplest way to stop an operation. And now we define one feature that throws an exception.
12:20
And what we do here is we call the operations throw, but we need to have an instance of the algebraic effect. And the syntax we use in Fusion for that is we use the type of the effect, which is my exception, from the environment. So .env means taking the innermost instance of that effect in the current environment
12:46
and calling that operation on it. When we do that, we should declare in the signature of the function that this function requires the effect my exception.
13:05
So this is very similar to a throws clause in Java. If I throw an unchecked exception, I need to declare that. Here, if I require a certain effect, I declare this with the exclamation mark. Now, I add some prints just to show what this code actually does.
13:24
And I want to call this function, this feature f now, to call it. I have to first install an instance of the effect. So I create an instance of the my exception effect here. Call use on is, which is a standard effect function that takes a lambda expression,
13:45
which then calls the code that is executed while this effect is installed. So adding some more prints that you see what is happening. And if I now run this code here, you see that it prints, the exception is installed,
14:02
it prints the before throw, throw directly jumps, very similar like an exception, out of the use here, and we continue with the, we are done. So the code after an operation that aborts here will not be executed at all. Very similar to exceptions.
14:22
Yeah. Now let me talk a bit about mutation. I told you that Fusion doesn't allow direct mutation of fields. So fields are immutable, which means if you do have code like that, we declare a field x, assign one, two, three to it, print it, and then assign two times x to another field x.
14:46
We see the expected behavior. But if we create a feature that prints this field x and try to compile this or try to run this, we actually get an error because the problem is this x here is not clear which one is referenced here
15:08
because we have two different variables here. There's two x's here, the first and the second, and they are only visible for the code following that. So we get an error message that there are two different x's and that source code position here doesn't know which one to choose.
15:28
So really every assignment creates a new field and these fields are immutable. To make them mutable, to get actually the desired effect that we can print x here,
15:46
we would have to create a mutable integer value which is with the base function, base library function mute, creates a mutable instance, assign this to the variable x, and now if we want to update this,
16:02
we don't create a new field which would be the colon equals operator, but we have an error operator which updates the value with a new value. If we run this now, it behaves first like the code before, but this time the show x function can actually access this single variable because now we have only one field left.
16:33
We can now analyse this code for the effects that this code requires, and if we do that, we see there are two effects.
16:42
There's IO out, this performs output, and there's the mutate effect because we have an update of a mutable field in our code. Now, not all variables, very few variables actually usually need to be mutable.
17:03
Here's an example of a small loop with an index variable counting from 0 to 9 and printing them. If we analyse this code for effects, we see that this only depends on the IO out effect.
17:21
The reason is that every loop iteration creates a new instance of that variable, so we don't update the I variable here, but we have one independent instance for every iteration of the loop. So no variable is mutated, a new instance is created for every iteration.
17:47
I want to talk a bit about error handling now and show how a function can produce an error and show them three different ways of how error handling could be done.
18:01
The function I use is just a divide that divides two integers and I call this in a show div function that calls divide and prints the result. And then I call this with three different value pairs.
18:22
And if I call this, I get, not very surprising, I get an error. There's a division by zero, the precondition of the division is not fulfilled. So there's the standard error handling in Fusion, but that's not very nice because you have the whole application for failing.
18:49
If you want to now somehow treat that error, what we could do is return an outcome which is similar to Rust's result,
19:00
which is basically a choice type between an error and an actually 32-bit integer and check the case. If b is zero, we return an error, otherwise we return the result of the division. And if we run this, now the application runs through, it doesn't terminate. And in the middle case, we print the outcome which is an error here.
19:29
But if we want to now actually, after calling the divide, want to know was this divide successful or not, we would need to check the cases.
19:41
So we need to distinguish whether we actually got a value or we got an error. We can do this with a match over the different choices. Now, an alternative would be to use the standard library try effect, which is kind of the default exception based on algebraic effects in Fusion.
20:07
And to do that, instead of returning an outcome, this would be just a function returning a 32-bit integer but requiring the try effect to be installed.
20:22
And now instead of causing an error, we would raise the error of the try instance in the current environment. So we don't need the else anymore because the raise would abort and would return immediately. So we could just continue with the code there.
20:42
And when we call the divide now, we have to call it with an instance of the try effect being installed. So just like before, this can be done through a base library function try that installs an instance and calls the lambda which is provided as a parameter.
21:07
And this can then be matched very similar to the outcome. But the big difference is that now the code in between, in between the position where the error
21:20
is and where we have this call, does not need to pass along these outcomes all the way. I'll come to an end very soon. But we can directly work with the i32s and the try would jump out directly. So we would see this outcome.
21:44
So the penultimate slide, the current slide, the status of Fusion is still very much in development. The language is getting a bit more stable recently, but there's still a lot of work mostly also in the base library.
22:01
The current implementation has two back ends, one running on a JVM and there's also a C code back end. And there's basic analysis tools available as I've shown you the effects analysis. Java maps actually very well to Fusion. There's a tool that allows calling all of Java APIs, creating Java APIs from a, Fusion APIs from a Java module that we can call into Java.
22:32
What doesn't work yet well is calling back from Java into Fusion, but there's at least in one way, it's a one to one mapping. We have effects to encapsulate non-functional aspects.
22:46
And I ask everyone, please have a look. Be happy for any feedback. Thank you for staying so long. I think time is over.
23:06
When you replace the return value with the tri page, is the match still needed? The match is still needed because this tri here installs the effect and an effect in the case of an abort has to provide
23:28
some way to join the value that is returned in the non-abort case with the value that is returned in the abort case. And for the tri effect, this join is just made by producing a value of type outcome, which is the choice between error and the value.
23:46
But there could be other effects that would just replace it by a default value in that case. So, it depends on the effect, but here it's definitely still needed. Do we have time?
24:04
I also saw a lot of code that uses the save function, which I presume uses that effect, but I didn't see the effect used in any of the examples. Okay. Yes, you took very good care. Thank you. Yeah, it is not decided yet where the compiler should be strict and require this annotation.
24:25
The current idea is that for basic code, we should not require this annotation, but for a public library function, we definitely want to know what are the effects. So, I don't want to enforce this for everything or for all the intermediate values.
24:44
And there's also some cases where only a static analysis of a whole application can actually determine what the effects are. So, static analysis plays a very important role there. I don't want to enforce too much typing basically for these effects here.
25:04
Another one is Java, for example, has this distinction between runtime exceptions and checked exceptions. And there are just these kind of exceptions that can have pretty much any code, like out of memory exception or static or so.
25:20
And I wonder how do you handle these kind of cases? Oops. They are shutting us down here. Okay. It's just a small hint. Very good. Actually, nothing of that is done yet, but I think I would like to get one step further and make it user configurable.
25:42
What are the effects that you want to have considered acceptable in your environment? Like you want to have maybe add some debugging print or some logging in somewhere nested in some internal function that shouldn't force you to add effects all over through the code.
26:04
So, we must have some set, some way to define for the debugging build. These are the effects that are in there and please don't complain about that. So, but we have to still see how we actually will do that.
26:21
Thank you for staying so long.