Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow specification of arbitrary syntax trees from grammars #12

Open
kneasle opened this issue Nov 19, 2020 · 6 comments
Open

Allow specification of arbitrary syntax trees from grammars #12

kneasle opened this issue Nov 19, 2020 · 6 comments
Labels
enhancement New feature or request 'extra fun challenge' An issue or PR that will take some time to get right.

Comments

@kneasle
Copy link
Owner

kneasle commented Nov 19, 2020

As said in the README, this is a very difficult challenge. I believe that the closest project to this is tree-sitter, and to be pragmatic I think that (at least initially) Sapling should try to use tree sitter as much as possible for parsing (even though it is not ideal for our use case). This way Sapling can actually function as an editor whilst we potentially build a more niche parsing system.

@kneasle kneasle added the 'extra fun challenge' An issue or PR that will take some time to get right. label Nov 19, 2020
@kneasle kneasle added this to Reviewer approved in Project of all issues Nov 19, 2020
@kneasle kneasle moved this from Reviewer approved to Review in progress in Project of all issues Nov 19, 2020
@kneasle kneasle moved this from Review in progress to To do in Project of all issues Nov 19, 2020
@kneasle kneasle added the enhancement New feature or request label Dec 21, 2020
@conartist6
Copy link

@kneasle there's a new parsing system you might consider, BABLR. It's built in a similar way to tree-sitter, but it's designed from the ground up to support your use case. For example, it makes a formal guarantee that print(parse(source)) === source

@kneasle
Copy link
Owner Author

kneasle commented Mar 3, 2024

@conartist6 - BABLR looks pretty cool, and something that I will keep an eye on for sure. My current feeling is that the best way to create a 'vim-like editor with cool AST stuff' is as a plugin into some other vi-like editor with tree-sitter support (neovim, helix, etc.), but if one wanted to make a fully AST-centric editor then a custom parsing system would come in very handy.

Apologies for the terribly slow reply, by the way - I realise it's been a hot while but I still wanted to get back to this :)

@conartist6
Copy link

Yeah I'm a bit out there, as my goal isn't to make one semantic editor but to make every existing editor semantic at the same time.

@conartist6
Copy link

conartist6 commented Mar 3, 2024

The way I describe it as transitioning editors towards being a lot more like web browsers. You can have many of them, they're written in a variety of languages but many share internals. You can even have terminal browsers like Lynx that do presentation very differently, yet still you can write a website once that will run on all (most) browsers.

If you think about it, a webapp is really more or less a set of automated tools for editing a DOM tree. We have all these amazing libraries and frameworks that can exist because at the end of the day everything comes down to editing that DOM tree that is embedded into the JS VM. There's a great explanation of the dynamics here: https://glazkov.com/2024/01/02/the-protocol-force/

I imagine that if a code-DOM existed and was shared by all IDEs there would spring up a rich ecosystem of tools for accomplishing many kinds of tree alterations. For example you'd have codemods that could help any project upgrade past breaking changes in its dependencies!

[Note: I think I did this explanation pretty well, so I'm copying it into the official docs.]

@kneasle
Copy link
Owner Author

kneasle commented Apr 27, 2024

That's a very wild goal (which is absolutely not a criticism!), and a really good blog article :) It would be really neat to have a thin waist like LSP but for syntax trees. Good luck, it seems like a plenty interesting problem to work on!

@conartist6
Copy link

Thank you! If you'd like to follow along, come join the Discord -- that's where I do all my thinking out loud at the moment and where I collect the people whose feedback I would want, which includes yours!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request 'extra fun challenge' An issue or PR that will take some time to get right.
Projects
No open projects
Development

No branches or pull requests

2 participants