Swift in Hammerspoon

[cmsj]

I think we're probably long past the point where Hammerspoon should get friendlier with Swift. We've built up a lot of great mechanisms for making ObjC<->Lua easy, but as @asmagill noted ~4 years ago in #928 - we are now in a world where most interesting discussions about Apple APIs are happening in Swift.

@heptal previously did some work to create Hammerspoon extensions in Swift, by manually mangling symbol names to match what was the Swift calling convention at the time. I have no idea if that convention is now fixed permanently, but either way it seems like a pretty fragile way of doing things.

I've been looking at a couple of projects which mix Lua and Swift and have come up with the following, as the simplest way I can find, of writing an extension in Swift. It doesn't require any special xcode build settings (other than SWIFT_VERSION being set in Project-Base.xcconfig because for whatever reason it currently resolves to unset) and can be loaded with one of our normal init.lua patterns.

It's worth noting though that there are some limitations (which are unchanged since @heptal noted them in 2017):

• Any C function which accepts variadic arguments (ie ...) is not available in Swift, we would need to provide alternatives in LuaSkin that accept va_list arguments
• Any complex C #define (ie macros, which a lot of Lua's API is made of) are not available in Swift, but they're relatively easy to manually recreate
• the luaopen_hs_ function (ie the extension's entrypoint after Lua dlopen()s the dylib) needs to be presented with a C calling convention. Swift has had an undocumented, unofficial @_cdecl() compiler hint for many years and there are efforts underway to legitimise it, so this seems like a low risk to take.

So, without further ado, here is the Swift example:

//
//  liblol.swift
//  Hammerspoon
//
//  Created by Chris Jones on 25/11/2021.
//  Copyright © 2021 Hammerspoon. All rights reserved.
//
// Heavily inspired by SwiftyLua, which is MIT licensed
// https://github.com/johndpope/SwiftyLua/

import Foundation
import LuaSkin

// TODO: Extend LuaSkin to offer va_* alternatives to variadic functions
// TODO: Map Lua #define'd macros into Swift since they are not available via compiler magic, see https://github.com/johndpope/SwiftyLua/blob/9b4e51effc5d5eb0e77de5200be1c3c8bfc65846/SwiftyLua/Macros.swift
// TODO(maybe): Figure out how to bridge Swift types into Lua types without going via ObjC

// START: Move these to LuaSkin
public typealias LUA_STATE = UnsafeMutablePointer<lua_State>
private let regFunc = luaL_Reg.create
private let nullFunc = luaL_Reg()

extension luaL_Reg {
    static func create(_ c_name: String, _ f: @escaping lua_CFunction) -> luaL_Reg {
        return luaL_Reg(name: (c_name as NSString).utf8String!, func: f)
    }
}
extension LuaSkin {
    // This wraps [LuaSkin sharedWithSkin:] which returns `id` (or `Any?` in Swift land, so we don't have to cast the return type every call)
    static func sharedTyped(with L: LUA_STATE?) -> LuaSkin {
        return LuaSkin.shared(with: L) as! LuaSkin
    }
}
// END: Move these to LuaSkin

// Declare the functions that will be registered for this library
private let lolLib: [luaL_Reg] = [
    regFunc("print", lolPrint),
    regFunc("echo", lolEcho),
    nullFunc
]

// C functions are exposed to Lua by way of being closures that are hinted to the compiler to be stored as C style function pointers, so they can be
let lolPrint: @convention(c) (LUA_STATE?) -> Int32 = {L in
    let skin = LuaSkin.sharedTyped(with: L)
    skin.pushNSObject("I AM SWIFT")
    return 1
}

let lolEcho: @convention(c) (LUA_STATE?) -> Int32 = {L in
    let skin = LuaSkin.sharedTyped(with: L)

    if (lua_type(L, 1) != LUA_TSTRING) {
        lua_pushstring(L, "ERROR: First argument must be a string")
        lua_error(L)
    }

    let input = skin.toNSObject(at: 1) as! String
    skin.pushNSObject(input)
    return 1

}

@_cdecl("luaopen_hs_liblol") // <- Note that this is technically unofficial, undocumented Swift compiler syntax
public func luaopen_hs_liblol(L: LUA_STATE) -> Int32 {
    let skin = LuaSkin.sharedTyped(with: L)
    skin.registerLibrary("lol", functions: lolLib, metaFunctions: nil)

    return 1
}

[cmsj]

So, with some basic exploration done, the question becomes, do we want to push this into a state where it's actually usable and an official part of LuaSkin? Thoughts @asmagill / @latenitefilms ?

[latenitefilms]

I know nothing about Swift, but love the idea of supporting it!

[cmsj]

After resisting Swift for a long time, I've been doing quite a bit of it over the last year and I kinda like it.

[cmsj]

If anyone wants to play with this, I've pushed up cmsj@d1622d6 with the above extension fully integrated as hs.lol.

[cmsj]

@asmagill @latenitefilms I keep thinking about this and while I think it's a good idea, I keep getting stuck on one thing that's been bugging me for ages - specifically, that our "do useful stuff" code and our "expose the useful stuff to Lua" code are inseparable.

Basically I think I would like to create a HammerKit framework that abstracts away all the useful stuff we do, and then call that from the extensions.

However, what I'm essentially suggesting here is that we rewrite all of Hammerspoon. We could do it in chunks rather than having to do it all at once, but it's a heck of a lot of work and some of the hairier modules are things I don't really understand because I didn't write them (e.g. hs.webview).
I have a vague hope that we might attract more people to work on the project if only because HammerKit.framework would be an extremely useful library for people who want to write a little macOS utility.

I know none of us are overburdened with free time though, so I figured I'd start with the discussion. I think I might have mentioned it a few months ago, when I did a quick experiment to see what it would be like to abstract the useful parts of hs.screen into a Swift framework: https://github.com/cmsj/Hammertime/blob/main/Hammertime/Classes/HTScreen.swift

[cmsj]

Further thought: Since it's possible to do this incrementally, we could do something like start with a module that is pretty self-contained and that we know needs updating, and that includes watchers, and see how it ends up looking. I would propose hs.wifi as the obvious candidate.

[cmsj]

As an additional thought, I think I would want to license HammerKit under the LGPL - it can still be used with MIT licensed code, or proprietary code, but if anyone does build another tool with it and makes improvements to HammerKit itself, they have to publish the code and we can benefit from it.

[latenitefilms]

I love the idea of a HammerKit Framework.

I don't think your "Hammertime" link is working - maybe a private repo?

I still haven't played with Swift at all - so I'm not sure how helpful I'll be anytime soon, but I'll definitely be keeping an eye on this, and try and get my hands dirty at some point.

[cmsj]

@latenitefilms made the repo public, sorry about that.

[asmagill]

I think this all sounds good, and I too am trying to familiarize myself with Swift, but I'm a little unclear on what you mean by "do useful stuff" code vs "expose useful stuff to lua" code..... do you have an example?

[joyspce]

this is good ideal, thanks

[cmsj]

@asmagill So like in libapplication.m after the rewrite, almost every Lua function we expose is short and does: 1) Validate input with LuaSkin, 2) call a single method on HSapplication, 3) push return values.
Compare that to, say, hs.screen where each Lua function we expose is a huge mishmash of Lua API and macOS API.

I much prefer the former, and in this example, I would move HSapplication into HammerKit. I think it would be cleaner to maintain, but it would also mean we'd be able to reuse all that functionality anywhere else in Hammerspoon without having to think about whether we can get to it via a lua_pushcfunction() or similar.