Static Swift/Kotlin renderers.

[pixlwave]

Hi, just starting to explore pkl for a project and we're really enjoying what we've seen so far.

One thing that surprised us though was that while you can evaluate pkl to YAML, JSON etc, you can't do so for Swift and Kotlin. We're using the code-gen in one part of the project to load in a pkl file at runtime and this works great, but there are other places where it would be more convenient to render directly to the language.

Our current workaround is Pkl → YAML → SwiftGen which works, but isn't that best as while you can set omitNullProperties = false, any null properties end up typed as Any?.

A simple example:

Settings.pkl

hidden variant: AppVariant
hidden fixed variantAsBrandedVariant: BrandedVariant? = if (variant is BrandedVariant) variant else null

defaultServer = variant.defaultServer
supportURLOverride = variantAsBrandedVariant?.websiteURL

settings.yml

defaultServer: my.server.com
supportURLOverride: null

Settings.swift (via SwiftGen)

// swiftlint:disable all
// Generated using SwiftGen — https://github.com/SwiftGen/SwiftGen

import Foundation

// swiftlint:disable superfluous_disable_command
// swiftlint:disable file_length

// MARK: - YAML Files

// swiftlint:disable identifier_name line_length number_separator type_body_length
internal enum Settings {
  internal static let defaultServer: String = "my.server.com"
  internal static let supportURLOverride: Any? = nil
}
// swiftlint:enable identifier_name line_length number_separator type_body_length

So we're wondering if there would be any appetite for such a feature?

[HT154]

This definitely seems useful! You can implement your own renderer directly in the language, it doesn't need to be a "feature" of the language.

You can see an example of how this is done for TOML here: https://github.com/apple/pkl-pantry/tree/main/packages/pkl.toml

[pixlwave]

Ohhhh interesting, thanks for pointing this out. I was looking at the YAML and JSON renderers and hadn’t realised this was possible.

[pixlwave]

Ok thanks @HT154, I've managed to iterate on the toml renderer to get something simple working for Swift. I'm stuck on one thing though. If I have a value that is null, is there a way I can get the explicit type information that was added to it? i.e. I have

website: String? = null

The value is obviously of type Null, so is there a way I can get the type hint for it?

[HT154]

Yep, you're looking for reflection!

pkl-swift's codegen is actually implemented in pkl and you may be able to import and use bits and pieces of it, or at the very least get some inspiration for how to apply reflection. See https://github.com/apple/pkl-swift/blob/main/codegen/src/internal/typegen.pkl

[pixlwave]

Thank you, that sounds great! Will take a look at this and see if I can get it working 🤞

[pixlwave]

It works! We've published our StaticCode renderer here:
https://github.com/element-hq/pkl-tools/tree/main/staticcode

It's not feature complete (PRs welcome!) but does everything that we need from it right now. Thanks for your help @HT154.

[bioball]

If you are using pkl-swift and want to avoid the Pkl dependency at runtime, you can eval Pkl into messagepack bytes during the build, and then embed these bytes inside your application. You can then decode the resulting bytes into the structs generated by pkl-gen-swift.

To eval into bytes, take a look at evaluateExpressionRaw.

To decode msgpack, take a look at PklDecoder.

I actually just created a sample application that uses this pattern for Go here, hopefully this is helpful: https://github.com/bioball/pkl-go-examples/tree/build-time-eval/buildtimeeval

Having Pkl data render to literals in the target language isn't a goal for us, because it's likely to be error-prone. It's hard to ensure that this rendering will match how the decoder/code generator works in that library.

[pixlwave]

Thanks for replying @bioball, this sounds an interesting route to take however I think we're probably going to go down the route suggested above for now as seeing the generated constants is really useful in diffs.