{"id":336,"date":"2014-07-04T08:28:19","date_gmt":"2014-07-04T14:28:19","guid":{"rendered":"http:\/\/dev.iachieved.it\/iachievedit\/?p=336"},"modified":"2014-07-04T08:28:19","modified_gmt":"2014-07-04T14:28:19","slug":"using-swift-as-a-scripting-language","status":"publish","type":"post","link":"https:\/\/dev.iachieved.it\/iachievedit\/using-swift-as-a-scripting-language\/","title":{"rendered":"Using Swift As a Scripting Language"},"content":{"rendered":"

Much fanfare accompanied the “playground” feature of Xcode 6 that allows developers to write some code and see the effect in realtime. If you have any experience with scripting languages such as Ruby or Python, you recognize this as nothing more than running the interactive language interpreter. With Ruby you type irb<\/code> at the command line; for Python try python<\/code>.<\/p>\n


\n$ irb
\n1.9.3-p448 :001 > fruit = ['apples', 'pears', 'bananas']
\n => [\"apples\", \"pears\", \"bananas\"]
\n<\/code><\/p>\n


\n$ python
\nPython 2.7.6 (default, May 30 2014, 22:21:15)
\n[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.34.2)] on darwin
\nType \"help\", \"copyright\", \"credits\" or \"license\" for more information.
\n>>> fruit = ['apples', 'pears', 'bananas']
\n<\/code><\/p>\n

For some reason Swift employs the more technical name of an interpreter, the REPL<\/b>, or Read-Eval-Print-Loop<\/b>. The interpreter reads what you entered, evaluates it, prints it, and then loops back to read. The REPL<\/b> isn’t magic, and its not anything new, it’s just new to those whose only experience with iOS and Mac development is Objective-C. Objective-C (and it’s C and C++ brethren) use the ECLR<\/b> paradigm: Edit-Compile-Link-Run<\/b>.<\/p>\n

It stands to reason that if you can run a Swift interpreter in Xcode, you can run it from the commandline. And sure enough you can you just have to dig down into the Xcode 6 package contents and find the binary to run. So open up a Terminal or iTerm 2<\/a> and type into your shell:<\/p>\n


\nexport PATH=\"\/Applications\/Xcode6-Beta.app\/Contents\/Developer\/Toolchains\/XcodeDefault.xctoolchain\/usr\/bin\/\":$PATH
\n<\/code><\/p>\n

Now, this assumes that the Xcode6-Beta application was installed into \/Applications<\/code>. If you are running it off of your desktop or some other location, adjust the path accordingly. For those unfamiliar with the Unix PATH<\/code> environment variable, check out Wikipedia<\/a>. Let’s fire up the interactive Swift interpreter!<\/p>\n


\n$ swift -repl
\nWelcome to Swift! Type :help for assistance.
\n 1>
\n<\/code><\/p>\n

Create an array similar to the examples above:<\/p>\n


\n 1> fruit = [\"apples\", \"pears\", \"bananas\"]
\n:1:1: error: use of unresolved identifier 'fruit'
\nfruit = [\"apples\", \"pears\", \"bananas\"]
\n^
\n<\/code><\/p>\n

Okay, so we know that we still have to use the Swift syntax for declaring variables. We can cope.<\/p>\n


\n 1> var fruit = [\"apples\", \"pears\", \"bananas\"]
\nfruit: String[] = size=3 {
\n [0] = \"apples\"
\n [1] = \"pears\"
\n [2] = \"bananas\"
\n}
\n<\/code><\/p>\n

Note that similar to Ruby’s interpreter, Swift echoed back what we declared. That’s the Print<\/b> part of the REPL<\/b>.<\/p>\n

Now iterate over the fruit<\/code>:<\/p>\n


\n 2> for f in fruit
\n:3:3: error: expected '{' to start the body of for-each loop
\n }
\n ^
\n<\/code><\/p>\n

Oops… we didn’t end the line with an opening brace. Swift clearly<\/i> prefers that the opening brace be on the same line<\/a> as the for<\/code> keyword, and we happen to prefer that style as well.<\/p>\n


\n 5> for f in fruit {
\n 6. println(\"One type of fruit is \\(f)\")
\n 7. }
\nOne type of fruit is apples
\nOne type of fruit is pears
\nOne type of fruit is bananas
\n<\/code><\/p>\n

To quit out of the interpreter you can type CTRL-D<\/b> or just type :q<\/code> and hit Return.<\/p>\n

Cool indeed. But what we’d really like is to treat Swift as scripting<\/i> language, not just another language we can play with in an interpreter. We’ll give that a try by writing a simple Swift script that accepts a list of filenames and then performs the Unix wc<\/code> function. Those that have dabbled in system administration or report generation know that wc<\/code> prints the number of lines, words, and characters in each of its input files. <\/p>\n

With the use of the -i<\/code> flag to the swift<\/code> executable we can do exactly that. Along the way we’ll continue to drive home the point that adopting Swift does not<\/i> mean you have to abandon everything you know about iOS and OS X application development.<\/p>\n

To make a point, we won’t be using the Xcode editor to edit the file wc.swift<\/code>, but rather our favorite Mac version of Emacs known as Aquamacs<\/a>. If you are familiar with Emacs editing modes, there’s even one for swift<\/a> that we like to use.<\/p>\n

The first line of wc.swift<\/code> should be<\/p>\n

[objc]
\nimport Foundation
\n[\/objc]<\/p>\n

This<\/i> is the real reason why developing in Swift already feels so robust; it doesn’t require abandonment of the core iOS and Mac OS X frameworks. Bringing in the Foundation Framework<\/a> links in all manner of classes ranging from NSCalendar<\/code> to NSXMLParser<\/code>. You will certainly almost always want to start your Swift files with import Foundation<\/code>, and it’s so fundamental that Xcode puts the line in for you when creating a new Swift file.<\/p>\n

The next line of code sets up the array of filenames that were (or will be) passed into our application. <\/p>\n

[objc]
\nlet filenames = Process.arguments
\n[\/objc]<\/p>\n

Now that we have our filenames we’ll iterate on them and use the fact that Swift String<\/code> gives us access to NSString<\/code> methods to load a string with the contents of that file. <\/p>\n

[objc]
\nfor filename in filenames {
\n var fileContents:String? = String.stringWithContentsOfFile(filename)
\n[\/objc]<\/p>\n

Before we continue let’s again look at why we had to declare fileContents<\/code> as a String?<\/code>. The reason is straightforward: imagine if the stringWithContentsOfFile<\/code> method failed for some reason, then what would fileContents<\/code> hold? Nothing.<\/b> That’s<\/i> why the variable is declared as an optional: it can either be a String<\/code> or it can be nothing at all.<\/p>\n

Since fileContents<\/code> is an optional, any further methods called on it would have to accompanied with an exclamation mark or<\/i> we would have to assign the contents to an unwrapped variable or constant. Trying to access methods using the optional results in:<\/p>\n


\nwc.swift:16:23: error: 'String?' does not have a member named 'componentsSeparatedByCharactersInSet'
\n var lines:Array = fileContents.componentsSeparatedByCharactersInSet(newline)
\n ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
\n<\/code><\/p>\n

So, we have to use exclamation mark:<\/p>\n


\n var lines:Array = fileContents!.componentsSeparatedByCharactersInSet(newline)
\n<\/code><\/p>\n

This is, however, poor form. If reading the file contents of the string did fail (for example, there was no file there to begin with), accessing it in this manner will crash with a likely fatal error: Can't unwrap Optional.None<\/code>. Instead we should use optional binding<\/i> to encapsulate our wc<\/code> routine:<\/p>\n

[objc]
\nif let contents = fileContents {
\n[\/objc]<\/p>\n

This line basically says, “If fileContents<\/code> is a String<\/code> and not the None<\/code> type then assign that string to the constant contents<\/code> and provide that constant to the true branch<\/i> of the if<\/code> statement.” That’s a mouthful. What this does is allows use to use contents<\/code> without the exclamation mark, because it is already unwrapped and we know that it is a String<\/code>. <\/p>\n

The remaining code is straightforward and illustrates once more that Swift provides access to the Foundation Framework. Using NSCharacterSet<\/code> and the NSString componentsSeparatedByCharactersInSet<\/code> method we are able to quickly pull apart how many lines and words are in our string. Tying it all together we get:<\/p>\n

[objc]
\nimport Foundation<\/p>\n

let filenames = Process.arguments<\/p>\n

for filename in filenames {<\/p>\n

var fileContents:String? = String.stringWithContentsOfFile(filename)<\/p>\n

if let contents = fileContents {<\/p>\n

var whitespace = NSCharacterSet.whitespaceAndNewlineCharacterSet() as NSCharacterSet
\n var newline = NSCharacterSet.newlineCharacterSet() as NSCharacterSet<\/p>\n

var lines:Array = contents.componentsSeparatedByCharactersInSet(newline)
\n var words:Array = contents.componentsSeparatedByCharactersInSet(whitespace)<\/p>\n

var numChars = countElements(contents)
\n var numLines = lines.count – 1
\n var numWords = words.count – 1<\/p>\n

println("\\t\\(numLines)\\t\\(numWords)\\t\\(numChars)\\t\\(filename)")
\n } else {
\n println("wc.swift: \\(filename): No such file")
\n }<\/p>\n

}
\n[\/objc]<\/p>\n

Finally, how to run this! The swift<\/code> binary provides the -i<\/code> switch for running in immediate mode<\/b>, which is what we want. So we type swift -i wc.swift<\/code> to run our code and…<\/p>\n


\n$ swift -i wc.swift
\nwc.swift:5:8: error: cannot load underlying module for 'Foundation'
\nimport Foundation
\n ^
\n:0: note: did you forget to set an SDK using -sdk or SDKROOT?
\n:0: note: use \"-sdk $(xcrun --show-sdk-path --sdk macosx)\" to select the default OS X SDK installed with Xcode
\n<\/code><\/p>\n

Oops. Remember that your Xcode development environment is capable of compiling applications for all manner of iOS versions as well as Mac OS X. There are<\/i> differences between the operating systems and versions, so you need to tell swift<\/code> which SDK you’re going to use (similar to setting your iOS SDK in Xcode). Thankfully swift<\/code> gives a nice little hint: \"use -sdk $(xcrun --show-sdk-path --sdk macosx)\" to select the default OS X SDK<\/code>. We’ll try that.<\/p>\n


\n$ swift -i -sdk $(xcrun --show-sdk-path --sdk macosx) wc.swift
\nwc.swift: -i: No such file
\n\t31\t184\t831\twc.swift
\nwc.swift: -enable-objc-attr-requires-objc-module: No such file
\nwc.swift: -target: No such file
\nwc.swift: x86_64-apple-darwin14.0.0: No such file
\nwc.swift: -module-name: No such file
\nwc.swift: wc: No such file
\n<\/code><\/p>\n

What the… What’s happening here is the default behavior of Process.arguments<\/code>. If there are no options presented to the application Process.arguments<\/code> will contain the commandline for swift<\/code>, which is not<\/i> what we want (obviously). In our example, Process.arguments<\/code> contained [-i, wc.swift, -enable-objc-attr-requires-objc-module, -target, x86_64-apple-darwin14.0.0, -module-name, wc, -sdk, \/Applications\/Xcode.app\/Contents\/Developer\/Platforms\/MacOSX.platform\/Developer\/SDKs\/MacOSX10.9.sdk, -color-diagnostics]<\/code>.<\/p>\n

To invoke the script in the intended manner we use the “dash-dash” option and then<\/i> provide the filename. $ swift -i -sdk $(xcrun --show-sdk-path --sdk macosx) wc.swift -- declaration.txt<\/code>:<\/p>\n

\r\n\t6\t35\t210\tdeclaration.txt\r\n<\/pre>\n
declaration.txt<\/code> contains:<\/p>\n
\r\nWe hold these truths to be self-evident,\r\nthat all men are created equal,\r\nthat they are endowed by their Creator\r\nwith certain unalienable Rights,\r\nthat among these are Life, Liberty\r\nand the pursuit of Happiness.\r\n<\/pre>\n
Was writing and executing this as straightforward as Ruby or Python?  No.  But it does illustrate you can<\/i> use Swift as a scripting language on your Mac and iteratively run bits of code without going through the Edit-Compile-Link-Run<\/b> cycle.<\/p>\n","protected":false},"excerpt":{"rendered":"
Much fanfare accompanied the “playground” feature of Xcode 6 that allows developers to write some code and see the effect in realtime. If you have any experience with scripting languages such as Ruby or Python, you recognize this as nothing more than running the interactive language interpreter. With Ruby you type irb at the command […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5],"tags":[],"class_list":["post-336","post","type-post","status-publish","format-standard","hentry","category-swift"],"_links":{"self":[{"href":"https:\/\/dev.iachieved.it\/iachievedit\/wp-json\/wp\/v2\/posts\/336"}],"collection":[{"href":"https:\/\/dev.iachieved.it\/iachievedit\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/dev.iachieved.it\/iachievedit\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/dev.iachieved.it\/iachievedit\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/dev.iachieved.it\/iachievedit\/wp-json\/wp\/v2\/comments?post=336"}],"version-history":[{"count":14,"href":"https:\/\/dev.iachieved.it\/iachievedit\/wp-json\/wp\/v2\/posts\/336\/revisions"}],"predecessor-version":[{"id":350,"href":"https:\/\/dev.iachieved.it\/iachievedit\/wp-json\/wp\/v2\/posts\/336\/revisions\/350"}],"wp:attachment":[{"href":"https:\/\/dev.iachieved.it\/iachievedit\/wp-json\/wp\/v2\/media?parent=336"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/dev.iachieved.it\/iachievedit\/wp-json\/wp\/v2\/categories?post=336"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/dev.iachieved.it\/iachievedit\/wp-json\/wp\/v2\/tags?post=336"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}