 We'll talk about it. So I assume that you're using something like ES6 or something like that, right? You use transpilers. How many of you just write JavaScript without transpilers? And you still enjoy it? It's hard to enjoy JavaScript. No, I tried it, seriously, but no, that doesn't work. So my name is Wagmi, I am heading a small consulting company called Tharka Labs. We do web and mobile development. So I have, I mean, I write a lot of JavaScript and I've been using ESX a lot these days. Before that I did a little bit of coffee script and anything that would not let me write JavaScript but still write JavaScript, I would take that actually. So my journey into functional programming languages came through Lisp, actually. So I started off with Scheme very early on and then I did Common Lisp and then I discovered Closure and so on and so forth and finally I discovered that, you know what, even if you have to write JavaScript, you don't have to write JavaScript, actually. So thanks to transpilers and so on and so forth. So my journey with functional programming properly started with, I would say Closure and Closure script, actually. Now the thing that I liked really about Closure and Closure script is that it was on the JVM. I mean, I was a Java programmer so all the libraries were just interop away or they had excellent wrappers over everything and they also had Closure script after a while and the best thing that ever happened to Closure script was David Nolan, actually. So he created OM and I think this, Bodil had given a talk called developing for the browser in the post FRP world as if there was some sort of an apocalyptic thing. But that is very true because after OM came in, it kind of gave this perspective of how you could use functional programming and immutable data structures and still have very, I mean, very well-reasoned user interface very well. And from that point on, I started discovering more languages like that. I actually had a brief sojourn with Elm as well and then Elm is very nice. But at the same time, Elm is, what do you say, I mean, it's still evolving and it's very opinionated on the kind of things that you can do with its type system and so on and so forth. It is pretty nice. And then I discovered PureScript, which is far more stricter, far more, what do you say, elegant form of functional, strongly type functional programming language targeting the browser. So usually as programmers, the first thing you do when you do that is you write Hello World or Hello PureScript. Now the trouble with writing Hello World in languages like Haskell is that there is this thing called the IOMONAD or this has a side effect. So just to clarify, how many of you actually, I mean, have done functional programming or understand it well, a few? So just to give you a very brief thing, the thing about purely functional programming languages is that when you have a function, it needs to be a referentially transparent. Like for example, you can't say, I mean, in JavaScript, you can say var a equals five, and then you can change your mind and say var a equals six, or you can really change your mind and say var a equals hello, right? I mean, you could not only change the value, but completely change the type and the representation of the whole variable. In functional programming languages in general, that is generally frowned upon, right? So you do not, although closure supports it, you can actually rebind vars and so on and so forth. In Haskell and other languages, it is not possible actually to do that. So the same is with pure script and languages like that. The idea is that you don't want to have side effects in your code. So whenever you execute a piece of code, you want to be, I mean, it needs to have a defined input, and as long as it has a defined input, it should always have a defined output, right? Now, but I mean, given the state of where the world is, it is not always possible, right? Because you want to be able to print things to the screen or go out and fetch, you know, stuff from the internet, from a web service, or actually make changes to the world around you. And that's the whole point of writing these programs. So if you're only doing purely functional programming languages without any side effects, all you would see is the box getting hot, as Simon Peter just says. There won't be any other thing. And that would be the only side effect of it. So the idea of functional programming languages like Haskell and pure script and MLSS, to separate the purely functional bits from the bits where you are mutating things or where you are changing things, or where it has side effects. Now, that's why you have a module here, and you have this main function, and the main function just says log, hello pure script, right? And it just writes it to the log, but you have to see the do block in there. So do block basically says that, hey, this main function is going to have a side effect. And the kind of side effect that it's going to have is something that prints to the console, actually. So I just put it out there, we will see what side effects are, we will see what pure functions are and so on and so forth. But I just wanted to say that that is in essence the difference between imperative programming languages and functional programming languages, is the insistence on purity. Just a little bit about pure script, it was created by this guy called Phil Freeman. It was very hard to find a photo of this guy actually. So yeah, I just stole it from his Twitter thing, he's a class that you want on Twitter and GitHub. So the thing is that I think given all the other Haskell-ish compile to JavaScript things out there like Faye, like GHC.js and all this, I think pure script is much better and much cleaner implementation of such programming languages than anything else. And I mean, like I said, I already mentioned I do a lot of JavaScript, I also do mobile. So in my day-to-day thing, I don't use pure script, I would like to use Haskell, but I don't use Haskell. So whatever I say, please take it with a grain of salt and other things. So I don't have like the production, you know, war marks in my chest or whatever, right? So that Tanmay is going to speak next, he's going to talk from 34 graphs. So he's going to say what happens when you put Haskell in production. But yeah, that's about all the slides I had actually. So we'll jump to code, I think. So let me know if you're able to see this. Most of it pink and all that, but anyway, so let me do one thing. Let me just change it to a white background. Maybe it'll look a little better than. It's okay, it's workable, so let's not worry too much about it. So when you start off a pure script project, there is this thing called pulp. That's what you want to start with, actually. So it's a npm thing, you can just install npm install hyphen gpulp and you'll get it. So all that is there in the documentation, I would just want to skip to that. So let me create a new directory. So you create a pure script project just like that. It's going to get a whole bunch of things and put it in there. Now, the way pure script is organized is that it uses bower. That's one of the other things I like about the pure script community is that it doesn't like to reinvent its tool. Like for example, Elm has its own Elm package manager. I mean, every single language has its own package manager. But these guys start, you know, you have a perfectly good package manager called bower that's just sitting around. Let me just use that, actually. So they're also very pragmatic, so let me just. So this is the main file that we saw. So you just have to run this, so yeah, so let me do white on. So this is even worse. I think it is better, right, slightly and the wrong directory. So is this better? Lightly, I suppose. So let's start doing run this. So the way you run this is you say pulp run and it's going to run this, right? And it's going to say hello, sailor. And let's look at the output it produces. So by default, it is going to output it in a common JS format. So you can actually have this built and check it into NPM if you want, actually. That's pretty cool. So you can see that it is there. So let's try adding a few functions onto this and let's see what happens. And it also comes with a raffle, actually. So you can run that with pulse PSCI. PSC is the compiler, PSCI is the, it's like just PSC and GSI from Haskell. So here you can ask for various things. You can say one plus two, it gives you the, it doesn't automatically import Prelude, after you have imported Prelude, then it'll, Prelude is the one which has all the standard functions that it comes, right? So the whole thing about Pioscript is it's types. So usually it has a few primitive types. Integer is one, it has one for floats. It's just number. You can do strings, and you can also do arrays. So it says that it's an array of integers. So usually JavaScript will allow you to do this. But here it'll say that you cannot unify, I'm sorry. Of course, it says that you can't unify int and a string. That's because it expects all the values in an array to be homogeneous, actually. It also has a record types. So you could do that person equals. So then, so these are just records. So it also supports the standard JavaScript way of building these. But then they automatically get strongly typed or associated with that. And then you can define functions the same way. So you can say square x equals x star x. This way you shouldn't give a live demo, so you should have prepared slides. Let me write it here. So let me declare the function here and use it there. What's wrong? It takes two ints and returns another int. Maybe it was not able to recognize that it's an int. I'm sorry. So two of them are, sorry. So you can say square of five and one second. I think I messed up my Apple pretty well. So yeah, so I mean, so here actually has a particular type, which takes a int and then it returns an int, actually. So if you see the implementation of this, so let me also do code output. So I didn't build it. Let me put this here. Yeah, something weird is happening. I'm pretty sure it worked before the, so okay. So the one thing that I wanted to show you is when you did a built, it actually built in the rest of the functions. When you optimize it, it'll only look for the functions that you need. Say for example, you only got the logs, actually. And we had the square function that was there. So it basically exports it and then it exports the particular values from the module, actually. So as you, even if you have other dependencies on your project, like for example, if you add a lens library or some other library, it'll make sure that it'll only get the libraries that you're interested in, actually. So let's start dealing with records a little bit. Yes, it did, actually. So it has a watcher as well. So you can say, this will keep watching the directory and then it'll keep running it. So ideally speaking, it should, I'm not sure why it's looking for patterns, src, star, star, star.js. It should be looking for your script files. So, PULP build should automatically find out that it is looking for the main module and it should build it, actually. But it is not. But however, if I give hyphen o, it finds out the mail module and then it's compiling it. For some reason, I think it's a small bug that we've run into for some reason, actually. So let's start writing a small listing here. So we're going to do a bunch of records. So we already saw how we do this. So we could say type person is actually, so we'll keep it simple here. Let's go include it in PSCI. So when I have this person, right? So I could do things like, and I could say this is a person, m.person, okay? But the thing is that, and I would also be able to say a.firstname and a.lastname, but I would not be able to just say, because it'll say that there is no instance found for prelude show main person. That means that there are type classes in PureScript. So think of type classes as interfaces in Java or protocols in Closure, where it says that you need to satisfy certain methods before it can do this. Now in the console, when you're doing this, I mean in the grapple, when you're doing this, to display a value, it expects it to have the show class implemented. So let's go ahead and implement the class. The thing is that now this is called a synonym type, in the sense that, say for example, this type is the same as a record. So PureScript does not allow you to have, I mean to do show classes or implement classes on synonym types, right? Because that will create ambiguity. So instead what it does, you have to do is you have to say this is a new type and give it a type constructor. Then what you can do is you can then say you can implement an instance of it. And when you are getting it, you just can't have the person object directly. But you have to understand that this is a, I mean we have a constructor on this. So you have to say a person of P and then you can then say, so now we should be able to show the person. So let me do this again. So here now I can, so doing this, I can do this, m dot person. Like I said, I already have a, so it won't let me do that. So now it actually displays the name, otherwise it wouldn't react. So if we have to update a particular name, then again we will have to set the change name. So you can take an object and you can then say, you can take an object and say new person and hence you could say, so the type of this method would be change name, colon, colon. So here this is the way in which you change the value in your record. So you take the record and then you change whatever value that you have to do and then do this. So what this does is it creates a new record from that and since we are using the type constructor, I mean, which is person, it will create a new person class and then return it from this. So let's see if that works. So this kind of sucks that I have to get back, keep doing this. So you have a and then say, so this changes. So this is the only way you can do changes in a record, right? I mean, so every time you have to make a change, so you always have to make sure that you make this change in place and then you have to do this. Now imagine if it's a deeply nested data structure. So let's do a couple of more iterations on this. Then things will become a little interesting. So I'm also going to have a new type called address and I'm gonna have a simple city and let me also add a bunch of phone numbers. So this guy would also have, so he also has an address in place with this. And so, for example, now let's also do one more thing. So you would have come across enums, actually. So in pure script and Haskell, the way you do enums is called the abstract data type, actually. So here you could do, say for example, you could have home, mobile, right? So this is sort of, I mean, it's not a simple enum where it's just these type constructors, so it could also be specialized on value, home of A or home of B or so on and so forth, actually. So we're gonna use this as well. So he's going to have a bunch of phone numbers as well, something like that. So let's see how we construct such an object. I'm gonna say a person who has addresses, I'm from Chennai, so state team, it's not yet there, so. And then we'll have some phone type is going to be used. So we'll fix the show appropriately. So as we know here, we only have, when we show the person, we are only showing the person in the last name. We want to show the other things as well. So we'll have to have the instance classes for those. We'll do the same thing for the phone as well. So I'm just going to see if the show method is working on this. If not, we may have to set up a show class for this as well. So now we can say, we definitely have a better way of doing this. But I'm just doing this for the sake of simplicity here. 13, Mr. Kama, I have a comma here. It says between home and here it should. Phone type needs show method on that. So one of the neat things about this thing is that you can do pattern matching. So you can simply say, what do we call it? M dot a person. So this basically shows that he's the first and last and lives here and so on and so forth. So the thing that we have to notice here is that when we implemented the show method here, we actually directly did a pattern matching on the constructor itself. So we can do pattern matching on the value, actually. So that is one really cool thing about languages like this is that you can actually do both partial and full pattern matching on this. So the famous example that's shown is like, yes. It will be an in exhaustive match and so it should complain, actually. No, it doesn't, actually. But it will bomb, actually. So let's do that. So I think instead of commenting this out, let's comment the home thing out. I know Haskell gives an error, but it doesn't check for, it bombs at runtime. Should definitely be a bug, should definitely be a bug. I mean, whenever you have these pattern matching things, it should be exhaustive. Especially on an ADT, it's actually quite trivial to find out what the data types are going to be on this one. That's a good guess. So now imagine if you have to change. So we did this change name, right? Now imagine if I have to write a function which is actually going to change the number that's there, right? Now that is going to be a pretty hard change function to write, if you have to write it like this, actually. So before this, let me, I actually wanted to show you this thing. So you could do, I need to get pure script list. Since it uses Bower, it takes it from the cached things, interesting. So it should have a, it has a constructor with an array, please don't do it. One of the things that I wanted to show is that here, it actually returns a maybe type even for a head, actually. So some things they've gotten, right? Like for example, head on Haskell would actually return the thing. And if you give an empty list for a head in Haskell, it would just bomb at runtime, actually. So, but some of those things here have been fixed. So it actually returns a maybe even on a head of a list, actually. So some of the things, but usually, you don't want to use list because list is very slow. Array actually maps onto the direct JavaScript array. And so it's usually faster, actually. Well, get to the constructor. It should, the cons should just work, actually. Yeah, so this would be, sorry, I think there is an empty list, there's an empty list. But yeah, I'll get to this later. The empty list is supposed to be, I mean, you could just cons on it and just get an empty list, but yeah, there's something wrong. I'm sorry about that. So anyway, coming back to this. Now, if you have to change this, it's going to get really difficult really quickly. So one of the ways in which you do these things is Lenset in your script, where you can actually go into a particular data structure and then replace it and then return back the original value. So I have a, I knew that I would get it wrong when I do it on there. So I spent the last half an hour writing one. So let me probably skip to the repo that I have for this. Now, this is a very similar sort of structure where you have the person and the address and so on and so forth. The way this works is that the PureScript Lens Library allows you to define accessors for a particular structure in your code. Like, for example, here, I've done this for the first name, right? The first is to destructure on the person data type and actually have a lens which reaches out to the actual function and take it. It's very similar to the Lens package in Haskell. Have you, has anybody done Lens packages in Haskell? Edward, you've done that. Okay, so it's very similar to that. But again, there are a few minor changes in that in a sense that the standard SDAB type signature still applies. But you have to be very explicit about defining a lens for a here, this thing here. Even though you say this person actually takes this record as of this thing, even you declare your lens, you have to specify it again for the type system to understand it. But your standard lens operators still apply. So let me keep it quick. So I have a bargaining with my thing here, just like how I had earlier. So in order to apply a lens, so this is a person and you can get the first name. So this should, right? So this will basically reach into it and get the first name. The advantage with this approach is that you could also do changes. So you can lift over this value and I think the operator is. I think I need to get the setter actually. I keep forgetting the, I'm not sure why they could just call it set. That would have been easier than these symbols actually. So you could also set in this. The advantage with this thing is however nested your data structure is, right? I mean, you can actually construct these lenses to that particular area. And then you can either set or get objects and it will return the whole person object as such actually. So that's pretty cool, I mean, it's, I mean, a lot of people come to Haskell and say, okay, they have these records and all these kind of things. And whenever you have to do mutability, it becomes a, or when you want to simulate mutability, it becomes a problem. So with this sort of thing, the simulating mutability is not that big of an issue actually. So going back, so let me give you some of the other things that are nice in the language. So you would have all done, right? I mean, JavaScript, Ajax calls, right? And you want to serialize Ajax calls one after the other. So the way you do it in JavaScript is you do promises. So you say this, and then you do a then, and then you give that, and so on and so forth, right? In a language like pure script, you don't have to do that. Or in a sense, there's a lot of syntax sugar that lets you go beyond that. Say for example, there's this thing called the effect monad, and you have a way of lifting the effects one after the other, so that you can actually do something like this. So before we do this, so let me start the server. Let me show you how this works. Let me run the server, so let me run this particular thing. So here what we are doing is we have a simple call to do localhost 3000 slash help, and after we get the result, we actually want to log its response, which actually would give back a result. So this, in fact, this would give back a result, which will then be passed to the long function, which will then have an effect where we will actually lift the effect. So lifting the effect is as good as committing that operation, it will wait for the effect to complete, and then it would do the next effect, actually. So it basically serializes these two values. In fact, you could do something with REST one again. So even though it looks like we are actually doing this, so lift F, so I can print that response out again. So for people who have done the bind operator, so what do does is that it actually is a syntactic sugar over multiple nested callbacks. So the REST one basically gets this, the result of it then gets passed to this, the result of it gets passed to this, and so on and so forth, actually. But because of that, it forms this bunch of closures where the variable REST one is still available here. Although it looks like a linear flow, like an imperative program, you just say, a equals b, or a equals one, b equals two, yeah, big deal, a will still be available after you have set b to two. But if you understand how the monadic bind works and how the syntactic sugar works, it is actually pretty cool that the effects that you have on top are still available when you have, when you have committed the other effects and they are still available in scope for you to do interesting things. So let me just, so it gets this help, and then it gets the list, and then it actually prints out the help response again, actually. The response value is still available after the call gets done. So let me talk a little bit about the server. It's an ExpressJS server that is being run, and it also has static middleware. So if you go to localhost 3000, I have a public facing site. I mean, React app, we'll get to the React app shortly. But if you go to, so this is what is getting displayed, actually. So let's quickly find out how this can be done. So Pioscript is not just an academic language. It can actually be used to do both client-side and server-side. So my earlier idea was to live code this, but then after I coded this, I decided that's not going to be possible, actually, to do it. So but let's start from the main function. It's usually easier from there, actually. So you can do multiple levels of foreign function interface in Pioscript, actually. Now the default way of doing FFI is that you do a, so you write a standard JS file, actually. And then this should be in common JS modules spec. And you should name the module the same as the module that you're going to do that. You need to, this commit is sort of important, actually, for the Pioscript compiler. And then you have to stick whatever functions you want into the exports of that. After which, you write a Pioscript wrapper for it. And then you do a foreign import. And if you see here, it is not a standard function, right? I mean, it's not like a Pioscript function where you could carry these values and so on and so forth. This is a function which actually, in fact, a special type called fn3, because it takes in three parameters. All the middlewares take three parameters where you have the request response on the next in this thing. So you take these three parameters. And that's how you do it. So if you want to turn this function again into a carryable sort of function, then you have a data.function package where you can do a run fm3. And then you can turn it into a carryable value, where it actually wraps this particular function into three different functions, where it passes the first value. And then it turns the lambda out, and then passes the second value, and so on and so forth. So that's how it works. Now the other way to do, I mean, that obviously sucks, right? I mean, when I started doing it, I actually wanted to do a React Native PureScript demo. And I just got lost in writing FFIs, and I gave it up, actually. So it uses too much FFIs that you have to write to do those things, actually. Instead, what I'm using here is something called as an easy FFI. It's a library on this. It's kind of cheating. Like, for example, so think of it this way. So I have an array of to-dos, actually. So this is our database. And then I create a, say for example, if I have to add something to it, I know that PureScript's array is actually JavaScript array, actually. So what I do is, the add function basically takes in to-dos, to-do, and an empty value. And I just do a to-dos.push to-do, and then it gives the index, and I just do a minus one and show it. So this is actually JavaScript code that runs for the to-do function. So if you notice here, it is actually all, but all these foreign functions have an effect on it, actually. So there is nothing which is pure, because it actually mutates the value of a variable in there. So in the similar sense, we have an unsafe foreign function, which actually gets the value from process.env.port or 3000. And the result of it is going to be an effect, which is going to be a string that's going to get lifted, and that's going to be in the port now, actually. And then we then set up the app on the port, actually. Now the app setup is pretty much the same thing that you would be familiar with in this thing. So all you have to do is you use certain middlewares, you map routes to handlers, and then on error, you do some error handling. So let's look at a couple of them. So the easiest thing is, of course, the help handler that we saw. It has a particular structure like this, and it just displays them into JSON, actually. So now we are going to actually turn a pure script record into JSON, and then give it up. So the way this works, so let's go to help handler. So the help object is a very simple record. So you just create name and bunch of things like that. So it looks like a JavaScript object, but it's actually a pure script record. And then you have the sendJSON. So sendJSON method is a part of this thing, Node Express app, so that knows how to do sendJSON, which is essentially JSON of that particular value. It just stringifies the thing and sends it. And that's pretty much what you have to do to actually write a sort of web service in your script, actually. Get the object. It could be the result of a computation, and you can lift it from a monad as well, and then send the value out, actually. So that is how the slash help method works. So let's go to the list method, which is an empty object at the moment. So here, in help, we didn't have to lift an effect. So whatever was the variable, we just did a sendJSON on that, actually. But in this thing, so the handler can also be a monad of this type. So what this does is it actually does get to do with indices. It's nothing but a very dirty JavaScript function, which just has to do the to-do-start map. And it's just a FFI again. So this is like, I mean, of course, your type guarantees with pure script are lost. But say if you're on a deadline like me, and you have to prepare for a talk and show that and still work, you could do something like this and get away with it. So of course, you could do the same thing with actual pure script records and do it properly. But here, what I did was I basically did a to-do-start map on it, and then this returns. But the fun part about it is it is an effect, actually. Since it is an effect, you can lift the effect into an actual object, which will turn it into the default value, so which is actually array of index to-do, actually. So index to-do is the type that we have declared on top, which basically says ID, description is done on whatever. So it turns it into an array of index to-do. And then it does a send handler. And then it does a send j on it, actually. And that's what you see as an empty array. So I have an included body parser here. So that's why I said get query param. But it is quite simple to include body parser. And then you can do get body param instead of get query param. So you can either deal with it as JSON or as URL encoded form data. So here, this would be slash ph. So this says that it's created. It's ID is 0. So if you go to list again, then it should have value. So let's look at what happens there. Again, we have an add to-do function, which basically has a to-dos. And then it has a record onto it. Again, as you would have expected by now, I showed the add to-dos function, which is a completely unsafe function. I mean, you're not supposed to write your script functions like this. Anyway. So you add to that, you push it. And then when you push it, you get the count of how many items are there in an array. So you just do minus 1 and 2. So that's pretty much what the delete set done, pretty much all of them are very similar sounding things. So that's all it is to create a web app with this thing. I will show you a couple of interesting things that happen here. One thing is when I go to the actual URL, it actually renders index HTML, which comes through the public middleware of that, actually. And also, if you see here, I'm also logging these things here. So whatever URL is visited, I'm logging them, actually. So let's look at how the middleware is done. So in fact, in the setup app, we say useLogger, and you do these things. So let's go to the logger function. So logger is just a handler. So it gets the original URL. This is the standard, this thing from Express App, the PureScript Express Library. And then it actually lifts an effect where it actually renders the URL, and it calls the next. So both the get your original URL and next are from the PureScript Express Library. And even there, it's just a bunch of FFIs all the way, actually, even in the PureScript library. So that's pretty much it. You can write your own. And I also, like I said, I use the static middleware. So this is a middleware that's entirely defined in PureScript itself. The other one is to, if you want to use middleware that exists in JavaScript or standard Express middlewares, you can just export it as a function, get it in via an FFI here. And then instead of saying use, you just say use external. And then point it to the FFI function, actually, middleware that you have. So I think it is quite usable now. I mean, you can actually start using PureScript to build server-side apps pretty easily. And hopefully, you would have time to do a much better job than to just do an unsafe foreign function and do everything that way, actually. So that's, I mean, I meant it as a whirlwind tour of different things. So I wanted to show one more thing, actually. I wanted to show that you can also do pretty decent UI with it. How many of you have worked with ClosureScript and GNOME here? Good. I mean, ClosureScript and GNOME, and Elm, anybody? Nobody in Elm, actually. So Elm had this idea called StartApp. StartApp basically said that any purely functional UI is going to have these three things. It's going to have a state. It's going to have action or a bunch of actions which take it from state to state. And then it's going to have a render function. And that's it. Those are the three things. So Elm also works the same way. I mean, you have the main, this thing. And then it keeps rendering it as you move the state. Although the action is not very explicit there. It's just an atom which keeps changing over time, actually. So in the same way, in PureScript, you have the lower level React where you can actually create class and do things and so on and so forth. But usually when you are writing or when you would like to write React applications in PureScript, you might want to use a library called Thermite, actually. So Thermite does pretty much the same thing. It has this concept of initial state. And then it has a way in which you perform an action or make the state go from or have a way to mutate the state in a managed way. And then you can then have the render method, which actually takes the state and renders it as such into the DOM. So let me start with the main method here, which is usually the thing here. So the main method actually creates a spec. I mean, takes the spec from here. And it creates a component out of that. Now this is the way when you use React, you would have to do a, even if you do this, I think you would have to do a factory of that particular class and then create a factory and pass it to it. Otherwise, if you're using JSX, if you just use the angle brackets, it gets turned into a factory, actually. And then you just render it to the body. Now body here is a method for me, right? I mean, so usually you do window.document.body. But we are in the managed PureScript world. Window may be available, document may be available, and you may have a body on it, right? So you can't just do that. So the way we do it is you actually go to DOM, ask for window, maybe it'll have a window. If you have a window, then you ask for the document on it. Maybe it'll have a document, and so on and so forth. Now actually this returns either object. So either is like saying whether it is successful or failure. So left is usually failure and right is successful. So you convert it to a maybe, and then you do unsafe just on it. I mean, so maybe type has these two options. It says maybe it has a value, or it has nothing, actually. So here, again, I am living on the edge, so I should actually do a pattern match and do it, or you can actually bind to it and still get that. Otherwise, you'll get nothing. But instead, what I'm doing here is I'm doing a fromjust, which will actually, I mean, I'm always expecting it to have some value. If not, it'll bomb on the client side, actually. From there, I just, I mean, this is just a help of function because the render method expects element and not a HTML element. So you have to turn HTML element to element. So it's just two libraries in the DOM thing which actually changes. So it's just a type help of that. And then I call the render method. So the r.render method is the reacts render method, which actually gets called. Now, our render method is very simple. So you get the context, actually. This is the same as the context that you get in Ohm's context. So you have a global coordinator of sorts that actually says, OK, where these components are, and what the tree is, and all that. So that is the context here. And then you have the state that's here. So state is something that we define, actually. So it's a type that we have. And it has just one thing right now. It just has a counter of an integer. I have three actions, increment, decrement, and reset. And I have an initial state where I set it to 0, actually. And then I also have one function which takes a particular action, takes an existing state, and returns a new state, actually. Just like how we did with earlier functions and lenses. But this just uses the standard function, because I only have one thing. I could have used lenses, and it would be easier here. So this basically takes a state. And if it's incremented, incremented, decremented, decremented, with reset, I just return the initial state as such and render it. Now the render method actually has, so if you notice for some of these, I have used underscores. The reason you use underscores is sometimes you don't care about what the particular types are. Like for example, one could be props, and another one is the context of the sender here. If you aren't sure about it, or if you don't care about it, you can actually put underscores. And your switch compiler will figure it out and bring it on its own. So here you have these things where this is just like OM, where you have a node, its attributes, and the children, actually. They're all in an array. But it also has these special prime values, where it directly takes children, and it doesn't expect attributes on it, actually. So that's the only difference. So here you construct the DOM, as you would construct it in OM or a similar library. And then you set up properties on it, where you say when it's on click, then you basically have a lambda where you apply the action to the context, actually. So here it's increment, decrement, or reset. I mean, you could have other values, like for example, if it has on click, the on click would actually give you an event object here. So if you want to do something special with the event object, then you can actually lift its effects from there, and then also do things from there. So those things would also work. So let me quickly show you how it works, like standard things. So I actually wanted to build a full to-do MVC, both the server side and the client side bits. But as I said, I got stuck with a lot of the FFI issues, so I kind of left it in between. And so I have a React app. I have a small demo, which does the HTTP calls and all that. I also have the HTTP calls, so theoretically it's still possible to integrate, but yeah, when I find the time. So in fact, this is kind of a whirlwind tour of what Pure Script is capable of. I knew I kind of went a little fast. But if you have any questions or other things, we can take it up now, and then we can kind of discuss if you want to hack on something else on this thing. We can also do that. Any questions? Most of the cases, yes. There are Pure Script D3 libraries available. But it's still pretty new. Like for example, the new FFI. I mean, earlier the way you did FFI before 0.7, so 0.7 got released recently. In 0.6 till 0.6, the way you did FFIs were you used to write these JavaScript functions as strings within code, actually. I mean, in your Pure Script code, you would actually have commented, I mean, fully stringified versions of the JavaScript function. And then you would say colon, colon, and then have the type on it, actually, which is very weird and very difficult to do it. Now that it has been separated out, I think there'll be a lot more FFI libraries coming up. It's a fairly new language, but definitely it's worth giving an eye on, because this brings a kind of rigor to JavaScript that usually does not, the JavaScript is not known for. And also, I think this is the best shot at having a strongly-tight language both on the server and the client, actually. I know GHS, JS, and FAI and other things are there. But I think Pure Script may be the, I mean, I would say there's enough community support behind it. I think Pure Script would be a clear winner in that space. So exactly, precisely the point. You can only use monads when the types are lined up, actually. And that's exactly what it does. So where did it go? So let's look at the type of this function, right? So as long as the first type, I mean, as long as the type is the effect, it will be the same, actually. So let's inspect the type on this, and it will be slightly clearer. I won't say a whole lot clearer, but so this type could be a little hard to read. So the thing is that it is of type exception Ajax, right? So as long as it's of type F, it's OK, actually. And you don't have to line it up. So as you put the stuff in, I mean, so we have lifted the effects of logs. So you're not seeing that, actually. But if you had done that, it will actually say effect this exception Ajax console log, actually, all the three of them. So for example, so here it will say the effect does not line up. So the effect is console log here, but the other one is the control monad act effect, actually. So which is a different monad, so the types don't line up when you just say log on it. That's the reason why we are lifting the effect on it, so that the type's line up properly. Any other questions? If not, I'm around. I'm easy to find. Thanks, guys.