Live data from Hacker News

Tree-sitter: an incremental parsing system for programming tools

github.com

71–80 of 138 posts

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

#71

Earlier quoted context omitted.

This is more a function of Ruby than of tree-sitter. The tree-sitter grammars for other languages are hopefully less inscrutable. For Ruby, we basically just ported whitequark's parser [1] over to tree-sitter's grammar DSL and scanner API. [1] https://github.com/whitequark/parser

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…

The code is obviously much simpler than its syntax - most importantly, its syntactical simplicity makes it way easier to deal with. So when you write the code to parse it you don't have to try to parse it in one fell swoop like you do in Whitequark.

So you can't read anything from a method call! I can make it so, if you're doing a class method (of any kind) you have to invoke the constructor, as described in "What is a method?" There's also a few new techniques like "new_class_method", which requires creating an object (of some kind) for that class... but what about that? It's not "I've just fixed Tree-sitter's problem"; it's that Tree-sitter hasn't yet resolved the problem yet - there are other parsing problems besides Tree-sitter in Ruby itself like those of classes (and classes are not part of Tree-sitter) and things that are known as "type-traits" and so on - so as it's not quite enough it can be done by other things. The reason for using LR grammar is that when it comes to this - what do I want from that grammar?

The point I'm making here is that LR doesn't give a reason for what you're doing. As a programmer you are trying to write code that is portable because - if it works in a domain you don't understand (such as Ruby) - then you don't know what you're doing is wrong. There can be a domain (as in any language) that's a lot more complex than this - but since we've got that, how can I be sure it won't mess up the code I'm writing?

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

#72

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-…

> "Paredit for TypeScript"

Is there a list of ideas for Structural Editing in C-like languages?

I can think of `extend-selection, `move to parent block`, `add arg to function`

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

#73

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

Thanks for building this. I had not heard of it before, but it looks great Are there more tutorials elsewhere on the Internet you would recommned, besides what is in the documentation?

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

#74
post #68
post #67

Earlier quoted context omitted.

Check out this video for a quick demo: http://emacsrocks.com/e14.html If you know a Lisp I recommend just giving paredit a spin for a few minutes, it's an interesting experience.

Looks like it's mainly tree/code manipulation. Typing code on the keyboard is probably the least taxing thing when it comes to software development. But I guess it will be nice once it has become a "reflex" rather then a conscious key-combo.

It's not so much about reducing the amount of characters typed, and instead moving the way you think about code from the character level to a more structural level.

Calling it a "reflex" is an interesting phrase! Tools like magit let me encode complicated processes into muscle memory, in a way where retrieval doesn't have to go through remembering and typing a string. Structural editing is similar.

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

#76
I'm curious to see if Tree-sitter can be used to provide fast and rich code navigation. I was able to implement simple goto definition/references [1], not sure if it can be used for more advanced navigation features in a language-agnostic way.

If you're interested, GitHub is already using it [2] for that purpose and Sourcegraph is experimenting it [3]

[1] https://github.com/alidn/lsif-os [2] https://github.com/github/semantic [3] https://github.com/sourcegraph/sourcegraph/issues/17378

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

#77

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

Is it possible to use tree-sitter to generate parsers in languages other than C? How hard would it be to modify it to create parsers in e.g. Java?

Edit: sorry, I just saw that you had answered that below.

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

#78
post #76

I'm curious to see if Tree-sitter can be used to provide fast and rich code navigation. I was able to implement simple goto definition/references [1], not sure if it can be used for more advanced navigation features in a language-agnostic way. If you're interested, GitHub is already using it [2] for that purpose and Sourcegraph is experimenting it [3] [1] https://github.com/alidn/lsif-os [2] https://github.com/github…

At GitHub, we're in the process of building a more precise code navigation system on top of Tree-sitter, that models language-specific name-resolution rules in detail.

Our currently-available code navigation system also uses Tree-sitter, but it is pretty simple; it just matches up references and definitions by their name.

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

#79

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

Thanks for building this. I had not heard of it before, but it looks great Are there more tutorials elsewhere on the Internet you would recommned, besides what is in the documentation?

Not that I know of, right now :(.

In the near future, we'll create some more GitHub-specific documentation that walks you through how to add advanced language support for any programming language on GitHub, by writing a Tree-sitter grammar, and then by writing the tree queries that are used for syntax highlighting, simple code navigation, and someday soon... precise code navigation.

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

#80
If curious, past threads:

Tree-sitter: new incremental parsing system for programming tools (2018) [video] - https://news.ycombinator.com/item?id=21675113 - Dec 2019 (28 comments)

Tree-sitter – a new parsing system for programming tools [video] - https://news.ycombinator.com/item?id=18213022 - Oct 2018 (25 comments)

Others?

Post reply on HN