In this session, you'll find out ways to streamline our contextual abstractions even further using implicit function types. In the last version of the conference management system of the last session, we got rid of explicit viewers arguments, but we still need them for using parameter clauses. So if I look at the worksheet here, then score rankings, delegate to all have these additional using clauses to track the set of viewers. One thing we could do to make this slightly more streamlined is to avoid the names of the viewers parameters. Instead of the names we just define a new global viewers function that takes the viewers and returns it. So now, essentially, whenever we have an implicit viewers in scope, we can just refer to it with its viewers functions and consequently we don't need to name the parameters anymore. That's a trick that one can basically apply everywhere one does context passing. So now it looks slightly more streamlined, but of course there's still the overhead of writing these anonymous using clauses. So the question is can we get rid of these as well? So to get to an answer, let's massage the definitions of rankings a bit. You know from the first half of the course that we can write any function with parameters, alternatively as a function without any parameters like this def rankings here. That takes on the right hand side, an anonymous function. The anonymous function has all the parameters of the original function and then continues with the functions body. So rankings alternatively could be written as the anonymous function that takes some viewers and does the sortBy. But something important got lost now in this translation, namely previously the viewers parameter was with a using clause. So it was an implicit parameter. But now in the anonymous function it's just a regular parameter that has to be passed explicitly. So we can get back to parity by writing a new kind of function arrow, question mark arrow here. The question mark signifies that we want the parameter viewers to be implicit, so that its argument can be inferred. In other words, that parameter now plays exactly the same role as the using clause on the left plate before. One interesting question is if you have a function like that, what is its type? For a normal anonymous function the type would be viewers arrow list of paper a normal function type. But for an anonymous function that represents a using clause on the left, the type is again written with a question mark. So the type is viewers, question mark, arrow, list of paper. And that type is called an implicit function type. So viewers question mark, arrow, list of paper is an implicit function type. What can we do with such types? Well, there are two rules that are relevant. The first rule says that values of implicit function types behave essentially like methods with using clauses. They get their arguments inferred in the same way. So if you have a value like F here of an implicit function type A question mark, arrow B, and a given instance of type A. Then the expression F expands to F using A. So the compiler will infer the value A as the correct parameter for the implicit parameter A of F here. So that's exactly the same as if F had been defined as a method like this F F, and then a using clause with A. The parameter inference is the same in each case. And then there's a second rule which makes implicit function types in a sense more powerful than just methods with using clauses. The rule is that implicit functions can get created on demand. What that means is that if the expected type of an expression say B is an implicit function type from A to B, then B will expand to an anonymous function where the parameter A, which is an implicit parameter is synthesized, is inferred. And that expansion happens before the parameter B is type checked. So that means when the compiler type checks parameter B there will be evidence of an implicit value of type A in scope which can be used inside. Now this might all seem quite abstract. Let's see how it applies in the concrete example of the conference management system. So let's use implicit function types in our conference management system. The first thing we do is introduce a type alias, we say type viewed of T is viewers question mark arrow T. That's in a sense, just for conciseness viewed of T expresses the fact that well, we return a result of type T and we also have the info who's viewing that result. So it's the same thing as the impressive function types here on the right, but it expresses that thing with a custom made namely the view thing here. Now we can apply two changes to our code. First we can replace every method signature that ends in a using clause and some result type with just the result type wrapped, interviewed. It's the same thing. We just essentially tried a parameter to the left two by using clause in the implicit function type. And second we replace every parameter query that has a function type like viewers arrow some type to be query which is a viewed of some type. So let's apply these changes to our worksheet. So we have a new type viewed, Like this and now we can replace all using clauses by viewed instances. And we further replace every query argument with explicit function type with the same implicit function type or rather it's viewed earlier. And that means that if we pass an explicit one now to query because it's an implicit function type, we have to add a using clause here and we have to do the same thing here. Well, let's see, we have some more problems here. My query now is the same thing, so you'd have set of person. And we can remove the viewers here, which is no longer needed because now query is already an implicit function type. So it will get an implicitly supplied viewers, our argument that we have been used and in the body of query. So what we've achieved in the end is the code that is quite streamlined. So essentially all we need to do is mention the viewed in the result type of the methods or in the type of the query parameters. And that will automatically track through the correct viewers that as implicit parameters. So it all works without us having to do anything explicitly in this example. So let's see what we have done here. We know that implicit parameters in using clauses, straight types for terms. That means the developer writes down the required type of the parameter, and the compiler infers a term that meets an expression or a value for it. Implicit function types go one step further, okay? They trade types now for the parameters. The development just needs to write down the return type of the method, and the compiler in first one or more method parameters that match the type. And from those parameters of course it will in further correct anonymous function bodies and also the arguments to the parameters. So basically at a very high level you just essentially specify a single type and the whole machinery will be generated for you by the compiler. Another way to see this is that implicit function types are second degree context abstractions. So what do I mean by that? Well, implicit parameters in using closes abstract over the context at the call site. So they are first degree context obstructions, and implicit function types allowed to abstract over using clauses as we have seen. Abstract in the original sense, they allowed to introduce a name such as viewed that can be used instead of writing an explicit parameter class. So together with type aliases, they enable abstractions of context abstractions, hence context abstractions of the second degree.
