[HN Gopher] Show HN: Tree-sitter Integration for Swift
       ___________________________________________________________________
        
       Show HN: Tree-sitter Integration for Swift
        
       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
        
       Author : daspoon
       Score  : 45 points
       Date   : 2024-08-20 17:03 UTC (5 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | Vayu wrote:
       | This is great, thanks!
        
       | mplewis9z wrote:
       | 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!
        
         | hprotagonist wrote:
         | you can write the grammars in swift now, not javascript.
        
         | daspoon wrote:
         | 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.
        
         | Terretta wrote:
         | 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.
        
       | Terretta wrote:
       | 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 wrote:
         | 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 wrote:
           | 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 wrote:
             | Would you mind sharing a simple example?
        
               | Terretta wrote:
               | _/ / replied via email_
        
       ___________________________________________________________________
       (page generated 2024-08-20 23:01 UTC)