SwiftShell 2.0 Readme

I finally got around to updating the SwiftShell 2.0 readme with some actual usage instructions:


An OS X Framework for command line scripting in Swift.


Put this at the beginning of each script file:

Run commands

Print output

Runs a shell command just like you would in the terminal. If the command returns with a non-zero exit code it will throw a ShellError.

The name may seem a bit cumbersome, but it explains exactly what it does. SwiftShell never prints anything without explicitly being told to.

Read More

How to use Swift for shell scripting

To be honest I’m not very good at shell scripting. It’s very useful for automation so I would like to be, but I just don’t like the syntax. For instance, this is how you check if a variable is greater than 100:

And here’s how to check if the file referred to in the first argument is readable and not empty:

Enough said.

So I would much rather use Swift, as the syntax is nice, very nice indeed. But the things that bash shell scripts actually are good at, like running shell commands and accessing the shell environment, are not that straightforward in Swift. Here’s how you can perform the various tasks using only the Swift Standard Library and Foundation:

Read More

Redesigning an API – Swift 2.0 style

SwiftShell (an OS X framework for shell scripting in Swift) is currently using the |> operator to combine shell commands, streams and functions, and |>> to print the results:

But Swift 2.0 is here, and it’s clear the way forward is protocols, method chaining and error handling. And being more explicit about what is going on. So for SwiftShell 2 I’m planning something like this:

Read More

Swift: mixing default values and variadic parameters.


As of Xcode 7 beta 6, Swift no longer requires variadic parameters to be last in the function definition. Also argument labels are no longer required when combined with parameters with default values. So this all works fine now:

The rest of this post is deprecated.

Read More

New theme and new host

Did not post anything last week, as I have been busy moving the site over to BlueHost and setting up a new theme. All because I wanted Swift code highlighting, and WordPress.com doesn’t support that. This of course took a lot longer than anticipated, but it’s finally done and if I do say so myself the new theme is simpler and easier to read. So all in all it was worth it.

Parser combinator operators in Swift

This is part of a series on FootlessParser, a parser combinator written in Swift.

Parser combinators must be one of the best things to come out of functional programming. They let you define intuitive parsers right in the code, without any need for pre-processors.

Like this:

where function1 and parser3 return the same type.

parser will pass the input to parser1 followed by parser2, pass their results to function1 and return its result. If that fails it will pass the original input to parser3 and return its result.

Read More

FootlessParser: updated documentation and readme

The FootlessParser project is finally becoming usable and now has brand-new documentation generated by jazzy. The readme has also received some attention and is now actually useful:

FootlessParser is a simple and pretty naive implementation of a parser combinator in Swift. It enables infinite lookahead, non-ambiguous parsing with error reporting.

Also check out a series of blog posts about the development and documentation from the source code.

Read More

Making a Numeric Type in Swift

Fabián Cañas demonstrates something similar to mixins in Swift (for operators):

By defining types (and protocols) around capabilities, and writing functions that target those capabilities, we end up with cleaner and remarkably reusable code when compared to implementing functionality targeting a specific type. The bulk of our final implementation has nothing to do with distances, time intervals, apples, oranges, or anything else. It reads more like a set of statements of fact that any future programmer could adopt if they so chose.

Swift: Associated Types

Russ Bishop has a clarifying post about Swift protocols and generics:

Type parameters force everyone to know the types involved and specify them repeatedly (when you compose with them it can also lead to an explosion in the number of type parameters). They’re part of the public interface. The code that uses the concrete thing (class/struct/enum) makes the decision about what types to select.

By contrast an associated type is part of the implementation detail. It’s hidden, just like a class can hide its internal ivars. The abstract type member is for the concrete thing (class/struct/enum) to provide later. You select the actual type when you adopt the protocol, not when you instantiate the class/struct. It leaves control over which types to select in a different set of hands.

But I do think he is too harsh on the functional programming hipster kids.

Add Result type and operators

This is part of a series on FootlessParser, a parser combinator written in Swift.

Add Runes and LlamaKit using Carthage


Footlessparser is using operators for map ( <^> ), flatmap/bind ( >>- ) and apply ( <*> ). Luckily the Runes framework has already defined these, and implemented them for optionals and arrays.

Each parse returns a Result, which has either a tuple containing the output and the remaining unparsed part of the input, or an error description if parsing fails. The Result enum is in the Llamakit framework, later replaced by antitypical/Result.

Add Runes+Result.swift


To implement the operators mentioned above for parsers it is very helpful to first implement them for what parsers return, i.e. Result. Gordon Fontenot did just that in this pull request to Runes. It was never merged, so it’s included here.

Rename Runes+Result.swift to Result+Operators.swift


I renamed the file later to make the name more descriptive and not so foreign for those who have not heard about the Runes framework.

Switch from LlamaKit/LlamaKit to antitypical/Result.


Later on the Llamakit project recommended switching to antitypical/Result. This lead to several changes:

  • the success and failure functions for making a Result moved to the Result type and became static instead of global. Which is good, functions only involved with one type should be defined in that type.

  • Result became a struct, not an enum. Which seems strange as it is either a success or a failure, never both. It was made back into an enum later.

  • the Result framework brought with it the micro frameworks robrix/Box, robrix/Prelude and robrix/Either. Especially Prelude has some basic functional programming functionality that will come in handy.