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 27 days ago [-]
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 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 27 days ago [-]
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 27 days ago [-]
you can write the grammars in swift now, not javascript.
Terretta 27 days ago [-]
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 27 days ago [-]
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 27 days ago [-]
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. :-)
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.
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.
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.