Live data from Hacker News

Tree-sitter: an incremental parsing system for programming tools

github.com

41–50 of 138 posts

Re: Tree-sitter: an incremental parsing system for programming tools

#41

Earlier quoted context omitted.

I didn't mean the tree-sitter grammar was not understandable - it's very understandable - I just can't work out how to managed to find such a concise way to express grammars. Even compared to Whitequark it's 1/3 the size. What's the unique thing you do that makes it so concise? It also seems somehow to be completely declarative? How have you managed to transform Ruby parsing to be context-free? For example where's th…

Ahh my mistake! :-) To be fair, we're cheating a little bit because the Ruby grammar relies so heavily on an external scannar, which is just under 1,000 lines of C++: https://github.com/tree-sitter/tree-sitter-ruby/blob/master/...

But for example how do you parse the difference between `x = 14; x` and `y = 14; x`? In the latter case `x` is a method call, and in the former it's a local variable read. I can't see where the parser maintains a set of local variables and where it queries this set. Is it somehow done declaratively? If so that's a huge achievement I don't think that's really been done before in a parser generator.

I really want to try tree-sitter for using in an actual Ruby implementation because it's so beautiful!

Re: Tree-sitter: an incremental parsing system for programming tools

#42

Tree Sitter is amazing. The parsing is fast enough to run on every keystroke. The parse tree is extremely concise and readable. It resembles an AST more than a parse tree (ie no 11 levels of binary op precedence rules in the tree). The parse tree emits specific ERROR nodes, so you can get a semi-functional tree even with broken syntax. I can't wait for the tools to get built with this. Paredit for TypeScript. Syntax-…

Neovim nightly already has some tools available as plugins. I'm using tree-sitter for syntax highlighting, text objects, and folding right now. Pretty satisfied so far.

Re: Tree-sitter: an incremental parsing system for programming tools

#43

Earlier quoted context omitted.

Ahh my mistake! :-) To be fair, we're cheating a little bit because the Ruby grammar relies so heavily on an external scannar, which is just under 1,000 lines of C++: https://github.com/tree-sitter/tree-sitter-ruby/blob/master/...

But for example how do you parse the difference between `x = 14; x` and `y = 14; x`? In the latter case `x` is a method call, and in the former it's a local variable read. I can't see where the parser maintains a set of local variables and where it queries this set. Is it somehow done declaratively? If so that's a huge achievement I don't think that's really been done before in a parser generator. I really want to tr…

[EDITED to make the example actually line up with OP's test]

There's no symbol table in the parser, so at parse time, we don't distinguish those cases:

  $ cat test.rb
  module Test
    def test1
      x = 14; x
    end

    def test2
      y = 14; x
    end
  end
  $ tree-sitter parse test.rb
  (program [0, 0] - [9, 0]
    (module [0, 0] - [8, 3]
      name: (constant [0, 7] - [0, 11])
      (method [1, 2] - [3, 5]
        name: (identifier [1, 6] - [1, 11])
        (assignment [2, 4] - [2, 10]
          left: (identifier [2, 4] - [2, 5])
          right: (integer [2, 8] - [2, 10]))
        (identifier [2, 12] - [2, 13]))
      (method [5, 2] - [7, 5]
        name: (identifier [5, 6] - [5, 11])
        (assignment [6, 4] - [6, 10]
          left: (identifier [6, 4] - [6, 5])
          right: (integer [6, 8] - [6, 10]))
        (identifier [6, 12] - [6, 13]))))
In both cases the bit after the semicolon just parses as (identifier).

For some use cases (e.g. syntax highlighting, depending on your colorization rules) it doesn't matter, and so we don't want to pay the cost. If it does matter (like in an actual implementation), then you'd have to implement this yourself and drive it by the parse tree you get from tree-sitter.

Re: Tree-sitter: an incremental parsing system for programming tools

#45

Earlier quoted context omitted.

But for example how do you parse the difference between `x = 14; x` and `y = 14; x`? In the latter case `x` is a method call, and in the former it's a local variable read. I can't see where the parser maintains a set of local variables and where it queries this set. Is it somehow done declaratively? If so that's a huge achievement I don't think that's really been done before in a parser generator. I really want to tr…

[EDITED to make the example actually line up with OP's test] There's no symbol table in the parser, so at parse time, we don't distinguish those cases: $ cat test.rb module Test def test1 x = 14; x end def test2 y = 14; x end end $ tree-sitter parse test.rb (program [0, 0] - [9, 0] (module [0, 0] - [8, 3] name: (constant [0, 7] - [0, 11]) (method [1, 2] - [3, 5] name: (identifier [1, 6] - [1, 11]) (assignment [2, 4]…

Right you could just have a phase to fix-it-up after parsing. Much better than trying to shoe-horn an imperative action into a nice more-pure parser. Great idea!

Re: Tree-sitter: an incremental parsing system for programming tools

#46
post #14

Earlier quoted context omitted.

I have used tree-sitter, but only for a very simple use case. The main shortcoming I am aware of are error messages, see here: https://github.com/tree-sitter/tree-sitter/issues/255 Tree sitter will basically always generate a parse tree, even for malformed input, in which case it will add ERROR nodes for the bits it doesn't like (it will also inform you that there were problems with the parse by setting a boolean att…

Ah I see, so the reparation isn't avoidable for now? That doesn't seem very appropraite for compilers then.

Why would it not be appropriate? The only annoyance I see is that currently you will have to generate a good error message from it yourself, but a first pass at the problem shouldn't be too onerous.

Re: Tree-sitter: an incremental parsing system for programming tools

#47

Hey, Tree-sitter author here. Thanks for posting! Let me know if you have questions about the project.

I've done two grammars for my own use in the last few months (well, one isn't quite complete yet) and it's been quite an enjoyable (learning) experience. Thanks for sharing this tool!

That's great to hear. Thanks!

Re: Tree-sitter: an incremental parsing system for programming tools

#48

Here's what it looks like to call it from Rust: https://github.com/tree-sitter/tree-sitter/tree/master/lib/b... Seems like this would make it much easier to bootstrap a performant language-server. Very cool; maybe that will be my next project.

We also have several of the language grammars published as crates: https://crates.io/search?q=tree-sitter (And doing the same for other grammars is a fairly painless process.) So if you're writing a tool for a single language (like a language server), it should be as easy as adding tree-sitter and tree-sitter-blah to your cargo manifest.

Awesome! Though my thinking was that it would have an especially large impact for languages that aren't popular enough to have their own LSP yet; you no longer have to be an expert in writing interactive compilers to set up a respectable LSP for a niche language, or even a home-grown one

Re: Tree-sitter: an incremental parsing system for programming tools

#49

Tree Sitter is amazing. The parsing is fast enough to run on every keystroke. The parse tree is extremely concise and readable. It resembles an AST more than a parse tree (ie no 11 levels of binary op precedence rules in the tree). The parse tree emits specific ERROR nodes, so you can get a semi-functional tree even with broken syntax. I can't wait for the tools to get built with this. Paredit for TypeScript. Syntax-…

Maybe I can finally have this syntax highlighting style: https://youtu.be/b0EF0VTs9Dc?t=900

There is an emacs package for this (maybe beta). I can't remember the name of it and Google is failing me.

EDIT: finally found it https://github.com/alphapapa/prism.el

Re: Tree-sitter: an incremental parsing system for programming tools

#50

Hey, Tree-sitter author here. Thanks for posting! Let me know if you have questions about the project.

I’ve been using tree-sitter via FFI from Common Lisp, but what I’d really like would be a way to write my own code generator so that the generated parser could be “native” lisp code. Otherwise, it’s an amazing tool: my only other complaint would be the lack of a grammar for objective-c which would be useful for a lisp/objective-c bridge I’ve been working on.
Post reply on HN