The very first Swift Blog Carnival is a wrap. Six folks took the prompt of Tiny Languages and ran with it in directions I hadn’t anticipated – from task runners and result builders to symbolic math and German verb conjugation. Thanks to everyone who participated!

Here’s the roundup.

Matt Massicotte starts the month with an excursion into the Tiny Languages of Task Runners in the spirit of the classic make. Thinking about it, it’s a bit weird that we have this powerful programming language and rely on scripting languages to build up projects. The community didn’t create any consensus to use a different tool and so you’ll find cmake in library projects, classic make here and there, then rake for projects that maybe embrace the CocoaPods legacy from a time where Ruby was still available as a first-class scripting tool on every Mac anyway. sake, the Swift equivalent, much more verbose by the nature of Swift, is also brought up. Matt ends with a surprise link to swift-sh – you need far less ceremony to make these scripts run, can import packages, and thus could maybe end up with a more capable build tool.

Chris Liscio describes how Capo can express commands via MIDI, powered by swift-parsing in “Capo’s Own Language”:

keyDown(rightArrow) {
  goToNextEntry(in: bars)
}

I don’t want to spoil the rest of the post. Just saying that swift-parsing is an amazingly capable package you should definitely try, and where working through the source is a treasure trove of cool patterns.

Nicolas “Zino” Zinovieff follows up with … maths! Look at this snippet from the symbolic expression DSL he built in Symbolic Math: (1 + 2 * "X") * (3 - "Y"). Apart from placeholders/variables being strings, that looks just like any other expression you’d write in Swift. Yet it’s a DSL for lazy evaluation for which you can plug in a set of values. (The symbolic expression library source itself isn’t shared, though. Maybe if enough people ask …? :))

As a German who suffered through years of school, sitting still, practicing the grammar of the language, “Why Konjugieren Needed More Than Markdown” caught my attention – Josh Adams wrote an iOS app to practice German verb forms. To highlight irregularities in the words, he extended the Markdown parser with 4 ASCII characters used as delimiters to express certain rule ranges and enhance the rendering. The trick is not just to treat the delimiters as 1:1 highlights, but to enable rendering modes that treat an uppercase letter in a special way:

The author writes $sAng$ to mean “the preterite of singen is sang, and the ‘a’ is the ablaut letter”.

Prompted by this Blog Carnival (success!), Warren Moore experimented with result builders for the first time to write a 3D scene DSL in Swift called Bismuth, imitating how RealityKit does it.

At the end of the post, Warren asks important questions: is it worth the work? What’s the benefit? One particularly quotable key question raised:

I think it’s easy to get enamored with the terseness of these types of constructs, because brevity feels like a clarity or power of its own.

Jesse Grosjean of Hog Bay Software shared a cool detail of his outliner in Bike: Outline Path Implementation, and how outline path expressions are parsed with swift-parsing. swift-parsing seems to get quite a bit of use :) A simplified version of Jesse’s actual parsing code is shared as a Gist and shows how /foo/bar/baz path expressions are being transformed into data.

That’s a wrap for April! If you’d like to host the next Carnival or suggest a topic, head over to the Swift Blog Carnival site and its GitHub repo.