Scripting

So far, you have only been executing code directly in the Scala REPL for the interpreter to read and evaluate. And while it’s easy enough to copy and paste or rewrite small snippets of code from the command line, as programs get larger and have more opportunities for errors, it becomes increasingly more tedious to encounter errors when the code is evaluated at runtime. Running code exclusively from the REPL also makes it difficult to store and execute programs at a later time. Scala scripts allow you to write your Scala code in any code or text editor that you want and execute them from the command line at a later time when you are ready. Using this scripting strategy, you can plan out a small program from start to finish before ever evaluating a line of code, writing each line as a set of instructions like a recipe that will produce a final result. This makes it easy to change your mind, delete a line of code, or refactor a step in the process. Also, once you have code that you can refer back to, you can share that code with your colleagues so they can execute it or contribute to it.

To get started, download or open your text editor of choice. This could be a simple Notepad on a Windows machine that takes in plain text, or it could be a more full-featured Integrated Development Environment or Code Editor. One of the main advantages of using an IDE is it will often highlight syntax for you to let you know when you’ve made a mistake before you’ve even executed the code. This leads to a better, more productive developer experience. There is a large range of features that comes with each IDE, and choosing the one that you feel most comfortable with might seem daunting. For a beginner, it is recommended to use a code editor that has a light feature set and a simple user interface to minimize the number of things you need to learn in order to get up and running quickly. Examples of these might be programs like VS Code, Sublime, or Atom text editors (all of which should have some form of Scala Plugin to assist with syntax highlighting of the Scala language). Other more professional and heavy featured options include IntelliJ IDEA and Eclipse. While the choice is ultimately up to you, I prefer VS Code for lightweight development as it has a very active community of plugins and support.

Once you’ve chosen a text editor, you can open it up and write a simple line of Scala code in a new document. For the sake of example, let’s use the expression 2 + 2. Save this document with the file name example_script.sc to your computer somewhere. The .sc represents the file extension necessary for your computer to interpret the file as a Scala script. Next, open up a terminal and navigate to the location where you saved your Scala script. VS Code has a native terminal that, when opened, will take you directly to the location of the current working directory which is really nice additional feature. From there, type in the command scala -nowarn example_script.sc. This will execute your script and ignore any potential warnings that the compiler might have about your code. You can execute any Scala script this same way by providing the script name or script file path that you want to run as an argument to the scala command. It may take a moment for your code to be compiled and executed (which will speed up the next time you run the script), after which… nothing will happen. Congratulations! You just wrote and executed your first Scala program. However, your terminal simply returned back to input mode waiting for another command. So what happened? Why didn’t we see the result of our expression?

Unlike the REPL, an executed Scala program will only print feedback to the console or terminal if the code you write tells it to. You might wonder why that is. Some programs might have a lot going on for any given command or user input. A program might request data from the Internet, reformat it, save a temporary file to your computer, split that file up into several other files, and store it to several database systems, for example. If each of those actions required some output to be printed to the console, the user might get overwhelmed by the response to their input command. It is also not very efficient to print to the console for every command as each print is an extra instruction that the computer has to process. By eliminating mandatory print commands, you have the ability to control the user experience and the efficiency of your program.

Up to this point, the Scala REPL has been handling the input, output, evaluation, and looping for you, so you wouldn’t necessarily have a choice as to whether or not each expression evaluation gets printed to the console. Outside of the REPL when working with a Scala script, you as the developer have the control as to whether or not the evaluation step of the REPL process needs to print anything back to the console for the user to see. The best way to demonstrate this concept is to build our own REPL process. Just like the windows command prompt or the Mac terminal or bash shell, we can create our own command-line tool that has a REPL process. Our example shell, like a command-line operating system, will take user input in the form of predefined commands, evaluate the input, print out only what we want the user to see, and then loop back to wait for more user input. First, let’s examine controlling what gets printed to the console.

Notice that because the print functions only take strings as arguments, the result of the expression 2 + 2 is coerced into a string and printed next to the “Same Line” string since it did not add a new line character to the end of the resulting string “4”. Alternatively, because the “Same Line” string was passed to the println function, a new line character was printed to the console so that the “New Line” string would end up on a new line. Also, because the “New Line” string was passed to a println function, any output that follows will also be on a new line.

Notice that, because the number that the user typed in is coerced by Scala into a String, this script explicitly converts the user input into an integer to ensure that the program behaves exactly how it is intended to run. If the user had entered a string value that cannot be converted to an integer, the program would have thrown an error rather than return an incorrect answer (which would have been a string concatenated three times, which for this particular expression would have resulted in the string “333”).

This example will execute exactly the same as it did before, but it now has documentation added to it for future reference making it easier to collaborate. It is, however, a best practice to ensure that you are not adding a comment for every line of code, especially if that code is reasonably well understood by most developers. It is usually only important to add comments to leave reminders about particularly complicated blocks of code that might be difficult to read or interpret or to leave a “to-do” item for yourself or others to implement at a later time.

Conditional Statements

Up to this point, both in the REPL and in Scala scripts, you have only seen simple examples of straight-line programs. Straight-line programs are programs that run through a set of linear instructions from start to finish evaluating each non-comment instruction exactly once. Knowing that, you might easily glean that your programs would have a difficult time doing anything reasonably complex as a straight-line program without writing a considerable amount of code. In order to create more complex programs that can perform dynamic logic evaluations, you must create what is called a branching program. A branching program uses conditional operators to evaluate optional branches in your program. Unlike a straight-line program where all code is executed once, conditional branches in your code are only evaluated if the conditional operator that precedes the branch evaluates to true. If it does not evaluate to true, the branch is skipped entirely. Alternatively, if the conditional operator evaluates to false, your program can execute a different branch. You can think of the conditional operator as a gatekeeper to the different branches in your code. In this way, your code can act similar to a “choose your own adventure” type story. Code branches that are preceded by a conditional operator are referred to as conditional statements or sometimes if/then/else statements.

Walking through this particular code, you can see that the first thing that we do is prompt the user to input a command. We store that input in the variable command. In this example, we are assuming that the user has typed 2 + 2 as their input, as shown in the terminal output section of the code listing. The next thing that we do is write our first conditional statement that evaluates whether the input string that the user provided contains the sub-string "+". Since 2 + 2 does contain the sub-string "+", the code branch contained within its curly braces executes and provides the output string "Addition command: 2 + 2". You’ll notice that because the if statement evaluated to true, the else code branch is ignored by Scala.

In the second conditional statement, we are checking to see if the user input contains the "-" sub-string. Because it does not, the condition evaluates to false and the branch that contains the code println(s"Subtraction command: ${command}") is ignored. Because the condition is false, Scala moves on to the else code branch which happens to contain a nested if statement. That statement checks to see if the user input contains the sub-string "help". Because the user input in our example does not contain that sub-string, the nested if statement’s code branch does not execute and Scala moves on to the nested else statement. That nested else statement prints out the string "Cannot evaluate command". Try running this same code with different user inputs to see how the output of the code changes similar to a “choose your own adventure” book.

In the last conditional statement, you’ll notice that it does not use any curly braces. This is considered inline shorthand for very simple expressions that can fit on a single line of your code. For reference, other languages have a concept called a ternary operator to provide this same logic of an inline conditional statement. For larger, more complicated expressions, it is a best practice to enclose your code branch in curly braces and provide proper indentation to show the nested nature of your code branch.

In this example, you can see an example of where the equalsIgnoreCase method is useful when comparing user input, since you don’t know what case they might have used. You can also see from this example that the else branch of each if statement is completely optional and is not used. You can chain together a series of if branches like this that only execute if the desired condition is met. You can see how this strategy might become a bit verbose over time if you need to evaluate a large set of conditions. For those scenarios, using the concept of pattern matching is a best practice.

Pattern Matching

You’ll notice some additional syntax in this example. The pattern matching expression captures the input of the command variable as a new variable c that can then be checked with a condition using the if keyword. If that condition evaluates to true, then the pattern is considered a match and its corresponding expression will be returned. Otherwise, Scala will continue checking other patterns for matches. It is worthy to note that in a pattern matching expression, the first condition that matches the pattern will be returned by the expression, even if the input being checked for patterns might match multiple patterns in the expression. Thus, it is important to consider the order of the conditions when you write them (which is why the catch all/wildcard variable is last).

At this point our Nebula shell program takes in three potential commands and returns output if those commands match a pattern. If none of those patterns match, the default case prints out feedback to the user that the command they typed was unknown. This operates fairly similarly to our description of the REPL process except that after the program receives the user input and prints out the corresponding output, the program ends. We need a way to loop back to the beginning of the script and await more user input to truly wrap up our REPL shell.

Loops

A loop is a method of control flow within your program that allows for the continual execution of a particular block of code until a defined condition is met. If that defined condition is never met, you may be trapped in an infinite loop that can cripple your computer, so you must always ensure that the condition that you define has the ability to be exited. In the event that you execute a script that gets stuck in an infinite loop, you can always hit Ctrl + C to kill your program and return back to the command prompt. There are three different types of loops that you will need to understand in software engineering: the while loop, the do/while loop, and the for loop.

Exception Handling

An exception is an error event that occurs during the execution of a program that disrupts the instructions sent to the computer for processing. If not handled, an exception will halt the progress of the program. This is often referred to as the program “throwing an exception.”

This example exemplifies how to manually throw an exception within the try block as well as how to pattern match within the catch block. In the last pattern matching example, we stored the value of the string that we were matching into the variable c. In this example, we do not necessarily need to store the value of the error that we are matching on; we just need to ensure we are matching it by its data type. Because of this, we are using the underscore wildcard character to tell Scala to catch anything that is of the following type but don’t worry about giving its value a variable name. When you execute this example, the script will print out “An error occurred.” because it matches on the generic Throwable type (of which Exception is a sub-type). If you change the try block to say throw new IllegalArgumentException(), then the catch block will print out “Illegal argument provided.” instead since the pattern will match on that type. Again, be conscious of the order of your pattern matching as the first pattern that matches will be executed. It is thus a best practice to have the most specific exception to match on at the top and the most generic exception at the bottom.

If we look back on our Nebula Operating System, we’ll see that there is not really an opportunity to use this new try/catch logic anywhere in our code. Right now, anything that the user types in will either match one of the commands or default to the catch all case. That being said, we are not really doing anything special with any of the commands either. At this point, we can start to implement some additional logic for each command so that we can do some interesting things with our operating system and handle any exceptions to our logic using the try/catch functionality.

This code shows that in the case where the command contains a “+” character we can take the command and split it into a list of strings or tokens and store that list in our tokens variable. Then, we check what the index of the plus operator is within that array and store that in the plusIndex variable. Once we have those two things, we can attempt to add any two numbers that occur before and after the plus character in our list of tokens using their indexes, which are derived by taking the plusIndex and subtracting and adding 1 from it for the number before the plus and after the plus respectively. From there, we can print the result of the addition expression to the screen. In this example we are explicitly attempting to convert any number provided as a string by the user into a Double type. If this fails because the user input a string before or after the “+” character that cannot be converted to a Double, the catch block will catch our error and allow our while loop to keep listening for additional user input rather than crashing. If the user only provides a “+” character or only gives the shell a number on one side of the “+” character, the catch block will catch the corresponding error. Also, if the user does not provide spaces between the tokens in their command, an error will also be thrown as the tokenization process will fail to split the command into the appropriate list and the catch block will catch the error. All of these exceptions are handled the same way in our example by simply printing “An error occurred trying to process an addition command” to the screen. If you like, you can handle each of these exceptions in a different way if you allow the code to execute without a try/catch block and observe what error is thrown. Then you can pattern match on the specific exceptions that are thrown and tailor the message to the user to give them additional information as to what went wrong.

Summary

In this chapter, you learned how to execute a Scala script which allows you to store code for collaboration and execution at a later time. In these scripts you learned how to take in user input, print output, and leave code comments where necessary. You also learned several control flow processes for managing complex logic in your scripts. These control flow methods included conditional statements, pattern matching, loops, and exception handling. You also started building your own operating system shell using a Scala script. In the next chapter, we will continue to build out this operating system using an abstraction construct known as functions.