Trying out the swift language…

Swift Logo

I was mulling over trying a new programming language for some time, but things have been quite busy. As I have been quite active in the real of schema.org and extractions recently, I mostly spent energy learning about turtle syntax. Python code is now running under version 3, and regularly there are new features in C++, and I had to hack some Typescript, but I wanted to learn a language of the new generation, either Rust or Swift.

I did not feel like spending a lot of time setting things up, so I decided to go with Swift, it is probably less l33t, but the goal was to hack something during short amounts of free time. My idea was to rewrite my old Java QuickDraw implementation. When I wrote that code, in the late 90s, Applets (and Servlets) were the coolest idea, and so my goal was to have a way to display Pict vector images in a web-page. A quarter century later, QuickDraw images are something from the real of retro-computing, and even the Preview application of Mac OS X does a poor job rendering them, so re-writing this library in Swift kind of makes sense.

So what about the language? The syntax is a bit different from the usual C-like stuff, but not much. Having different constructs to declare variables and constants is nice, although the let keyword brought back memories from BASIC. What struck me is how present error-handling was, both in the form of exceptions and optional values. Both notions exist in one form or another in Java, C++, or Python, but here they are much more explicit in the language: if you call a function that can throw you must specify this with a try statement, and the if let statement allows you to assign a temporary to a variable and execute a block, which is what you want to do most of the time. The other nice construct is the question mark operator, that allows to chain optionals within options, i.e. a?.b?.c gives you an optional of the type of c with the value of c if there is one.

The construct I found most interesting is ranges. These can be used in loops, to check membership, for array access and for case statements, the language has shorthand notations for open and closed ranges. This struck me because Python supports the first case, the handling of the second is bad, and the last case does not work, because range and slice are different types, and this seems to be important in Python…

So you can write something like:

for index in 0..<n { … }

Which gives you the classical loop from 0 to n - 1. Nothing ground-breaking, but this is makes for simple and readable code. In my case, the range notation really helped for my parser. The Quickdraw language is basically a sequence of opcodes, with specific actions defined by the position in the range, so the interpreter has the following lines:

  case 0x30...0x34:
      return RectOp(same: false, verb: QuickDrawVerb(rawValue: opcode - 0x30)!);
  case 0x38...0x3C:
      return RectOp(same: true, verb: QuickDrawVerb(rawValue: opcode - 0x38)!);

In case you are wondering, the exclamation mark is an operator that dereferences an optional, as construction of the QuickDrawVerb enum from a raw integer value could fail – don’t worry, values from 0 to 4 are ok. Case statements support much more powerful patterns, but I did not yet find a use for them.

What else? I like the fact there is a default mechanism to initialise enums from integers. I like the fact there is a class (OptionSet) to represent C-style bit-sets. I liked the distinction between class (passed by pointer) and struct (passed by value) introduced by C♯, which makes it natural to create small structures. Generally, a lot of things are nice, the default implementation of description (the equivalent of ToString() in Java) is good enough for debugging, the way you do formatting by just using locale variables is convenient, i.e. you can write:

print("x = \(x)");

I also like the idea that an enum values has some attached data, making it also a replacement for the C unions, although I have not used that feature yet, tuples are as easy to use as in Python. There is a string class that supports Unicode, but the Character class is not a single codepoint, but an extended grapheme cluster, finally a language that gets strings beyond ASCII<… Generally, I like the language, while it took me some time to get used, it was nothing serious, and I managed to quickly write a good chunk of a functional parser in code I feel is clearer and more efficient that it would have been in Python or Java. Which is quite impressive if you consider that have way more experience with these and that both of them will generally produce slower code. What I have yet to understand is how it connects to the low-level infrastructure where the raw pointers are lurking, which will become a theme once I move into converting pixmaps around. Stay tuned…

4 thoughts on “Trying out the swift language…”

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.