![]() Having your whole program be just one I/O action seems kind of limiting. An I/O action will be performed when we give it a name of main and then run our program. So, when will an I/O action be performed? Well, this is where main comes in. The empty tuple is a value of () and it also has a type of (). Printing a string to the terminal doesn't really have any kind of meaningful return value, so a dummy value of () is used. An I/O action is something that, when performed, will carry out an action with a side-effect (that's usually either reading from the input or printing stuff to the screen) and will also contain some kind of return value inside it. We can read the type of putStrLn like this: putStrLn takes a string and returns an I/O action that has a result type of () (i.e. First, let's look at the type of the function putStrLn. helloworld.Īnd there we go, our first compiled program that printed out something to the terminal. Okay! With any luck, you got something like this and now you can run your program by doing. Compiling Main ( helloworld.hs, helloworld.o ) We're actually going to compile our program! I'm so excited! Open up your terminal and navigate to the directory where helloworld.hs is located and do the following: Save that file as helloworld.hs.Īnd now, we're going to do something we've never done before. Looks pretty much run of the mill, but it isn't, as we'll see in just a few moments. We just defined a name called main and in it we call a function called putStrLn with the parameter "hello, world". So, for starters, punch in the following in your favorite text editor: If you're in Windows, I'd suggest you download Cygwin, which is a Linux-like environment for Windows, A.K.A. Hey! For the purposes of this chapter, I'm going to assume you're using a unix-y environment for learning Haskell. But now, after eight or so chapters, we're finally going to write our first real Haskell program! Yay! And sure enough, we're going to do the good old "hello, world" schtick. We've also explored the standard library functions that way. Up until now, we've always loaded our functions into GHCI to test them out and play with them. With those two parts separated, we can still reason about our pure program and take advantage of all the things that purity offers, like laziness, robustness and modularity while efficiently communicating with the outside world. ![]() It turns out that Haskell actually has a really clever system for dealing with functions that have side-effects that neatly separates the part of our program that is pure and the part of our program that is impure, which does all the dirty work like talking to the keyboard and the screen. If a function can't change anything in the world, how is it supposed to tell us what it calculated? In order to tell us what it calculated, it has to change the state of an output device (usually the state of the screen), which then emits photons that travel to our brain and change the state of our mind, man.ĭo not despair, all is not lost. ![]() While functions being unable to change state is good because it helps us reason about our programs, there's one problem with that. Our function for inserting into a binary search tree actually returned a new tree, because it can't change the old one. For instance, when we were making a binary search tree, we didn't insert an element into a tree by modifying some tree in place. In an imperative language, you have no guarantee that a simple function that should just crunch some numbers won't burn down your house, kidnap your dog and scratch your car with a potato while crunching those numbers. While this may seem a bit limiting when you're coming from an imperative world, we've seen that it's actually really cool. If a function is called two times with the same parameters, it has to return the same result. The only thing a function can do in Haskell is give us back some result based on the parameters we gave it. ![]() In Haskell, a function can't change some state, like changing the contents of a variable (when a function changes state, we say that the function has side-effects). Whereas in imperative languages you usually get things done by giving the computer a series of steps to execute, functional programming is more of defining what stuff is. We've mentioned that Haskell is a purely functional language. ![]()
0 Comments
Leave a Reply. |