Show HN: Tree-sitter Integration for Swift

[daspoon]

https://github.com/daspoon/tree-sitter-kit

I have created a Swift package (https://github.com/daspoon/tree-sitter-kit) enabling tree-sitter parsers to be written in Swift; specifically, as an array of production rules which map symbol types to pairings of syntax expression and type constructor. A member macro derives a tree-sitter grammar and embeds the generated parser in its expansion.

This project is a work in progress, and I will be grateful for any feedback.

Thanks, Dave

[mplewis9z]

Since there's already a binding for Swift that's listed on Tree-sitter's site (https://github.com/ChimeHQ/SwiftTreeSitter), it'd be great to list in your ReadMe how your implementation differs/is better than that one!

[Terretta → mplewis9z]

Seems to me this is a case of the Sesame Street song, "Which one of these things is not like the other ones?"

There are bindings for Swift, parsers for Swift source, and this utility kit for Swift which seems more focused:

- Tree-Sitter Bindings for Swift provides the foundational tools to use tree-sitter’s parsing capabilities in Swift: https://github.com/ChimeHQ/SwiftTreeSitter

- Tree-Sitter Parser for Swift is a specific implementation that allows tree-sitter to parse Swift code: https://github.com/alex-pinkus/tree-sitter-swift

- Tree-Sitter Kit is a higher-level toolkit that simplifies creating and using tree-sitter parsers in Swift, providing a more integrated and Swift-friendly approach to defining and working with grammars and parsed data structures: https://github.com/daspoon/tree-sitter-kit

This Tree-Sitter Kit looks like a convenience layer on top of the tree-sitter system, designed to work smoothly within Swift, making the process of creating and using parsers more straightforward and idiomatic within the Swift language itself.

[daspoon → mplewis9z]

That's a good point, thanks.

My understanding is that work exposes nearly the full tree-sitter runtime API, but relies on tree-sitter's standard tech for converting javascript grammar specifications to separately compiled C code.

This work instead exposes a minimal subset of tree-sitter functionality, but enables defining parsers entirely in Swift -- eliminating the need for javascript and mixed-language targets, and streamlining the build process.

[hprotagonist → mplewis9z]

you can write the grammars in swift now, not javascript.

[Terretta]

It’s fantastic to see new tools or kits for Swift that are recent, actively maintained, and doing genuinely interesting things.

As “just saw it, thanks for sharing” feedback, I’m curious about whether this could simplify building and handling DSLs directly in Swift, especially for OS projects making leveraging commercial LLMs with agents, functions, and structured data easier for end users.

The ability to define grammar rules and automate parse tree translation in Swift should make managing structured inputs and outputs easier—key for ensuring LLM interaction reliability (staying on point and interoperable).

Your current approach looks promising for starting to handle basic DSLs and providing feedback to users in their editing tools, along with structured data, though I’d have to dig in see how it scales with more complex grammars, and have ‘starred’ your repo to watch for updates around error reporting and editing support.

[daspoon → Terretta]

That's an interesting angle. I haven't thought about applications much beyond hobby programming languages. I hope to make some progress with error reporting soon. Thanks.

[Terretta → daspoon]

I, more or less, want to make a 'hobby programming language' for letting users do certain types of work with LLMs, without them realizing they're even hobby programming. :-)

[daspoon → Terretta]

Would you mind sharing a simple example?

[Terretta → daspoon]

// replied via email

[Vayu]

This is great, thanks!