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.

Sign up for GitHub

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

Jump to bottom

Thoughts on language tooling? i.e. Language Server Protocol/tree-sitter #571

Open
acxz opened this issue Jun 13, 2024 · 11 comments
Open

Thoughts on language tooling? i.e. Language Server Protocol/tree-sitter #571

acxz opened this issue Jun 13, 2024 · 11 comments

Comments

@acxz
Copy link

acxz commented Jun 13, 2024

Hello SysML Team!

Please feel free to transfer this issue over to another repo as you see fit.

I was wondering if there are plans to create a Language Server Protocol (LSP) implementation for SysML v2 or creating a tree-sitter parser. Both of these tools will allow sysmlv2 integration to any editor that has support for these tools (which is pretty much any popular editor such as vscode, neo/vim, among others including our pilot implementations of jupyterlab and Eclipse IDE.

If you want to learn a bit more history about the LSP: https://www.eclipse.org/community/eclipse_newsletter/2017/may/article1.php

Also a tldr in case it helps: Tree-sitter provides syntax detail at the source file level in a quick manner (i.e. as you are entering keystrokes), LSP provides semantic detail at the project level at a slightly longer timescale.
@acxz
Copy link
Author

acxz commented Jun 13, 2024

It seems like Sensmetry may have a language server implementation with their SysIDE vscode plugin. However, their implementation is embedded within their plugin and would have to be separated out for everyone else (i.e. other editors/plugins) to use.

It makes sense to me that the sysml team be in charge of the language server protocol that will be used by various tools and editors.

@hpdekoning
Copy link
Member

hpdekoning commented Jun 13, 2024 via email

@acxz
Copy link
Author

acxz commented Jun 13, 2024 •
edited
Loading

Oh, I didn't realize that SYSON also used LSP! That makes me happy!

I guess my follow up would be a request for a repo where only the LSP implementation exists.

A big selling point of LSP is the fact that you don't have to implement it for every editor/plugin, but unfortunately that seems to be the case for the current sysmlv2 landscape (of course the tools are limited and sysmlv2 is in its infancy).

Would there be any motivation for an "official" LSP implementation that would be used by say the pilot Eclipse, pilot jupyterlab, the syside vscode plugin, syson, etc?

@himi
Copy link
Member

himi commented Jun 13, 2024 via email

@acxz
Copy link
Author

acxz commented Jun 13, 2024

o.O I wasn't aware of xtext, that is definitely a good start to an LSP implementation, but taking a look at SysIDE's implementation might a good first step (they may already support all the LSP features and it might just be a matter of splitting out the implementation so that other editors/plugins can use it. See the syside issue I created)

Maybe the SysON project takes a similar approach but unfortunately their
metamodel is not the same with that of SysMLv2-Pilot-Implementation.

I might be misunderstanding you here, but sysmlv2 is sysmlv2 no matter what tool you are using right? If SYSON is parsing .sysml files, that is all that matters. I don't think an internalized metamodels matters for an LSP implementation, just the language.

LSP is fairly good but not so responsive

I agree that LSP can be slow, but that is why languages have both tree-sitter and LSP, tree-sitter for the super fast incremental updates that happen in the source file and LSP for the semantic understanding at the project level.

and not so useful for advanced language processing.

Could you clarify this? What is your definition of advanced here with respect to an actual feature? Is there something in mind that isn't part of the LSP spec: https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/? Is there an alternative you have in mind?

If it needs much development effort, I will simply use Lezer on CodeMirror for that purpose.

Lezer is a parser and falls in the same category as tree-sitter, however, tree-sitter is much more popular and supported in various editors, whereas Lezer was made primarily for CodeMirror and web based editors. I personally think of Lezer as a light-weight javascript implementation of tree-sitter (which is in C). You can find more info on the comparison on Lezer's website and forums. I tried search but couldn't find a Lezer parser for sysmlv2 as of yet, and would recommend that a tree-sitter parser is created/popularized for sysmlv2 over a Lezer parser.

@himi
Copy link
Member

himi commented Jun 13, 2024 via email

@acxz
Copy link
Author

acxz commented Jun 13, 2024

Rather, I want to make an advanced intelligent SysMLv2 editor on top
of SysMLv2 Pilot Implementation.

The Pilot implementations will become advanced intelligent editors if we implement LSP for the sysmlv2 language, fulfilling that request as both the Eclipse and jupyterlab have LSP support.

I can simply say that currently I'm not so interested in supporting various IDEs.

This will be a (fortunate) by-product of using LSP.

I think we are all on the same page here with having better language tooling and code intelligence features for sysmlv2.
Moving forward the question I have is does the sysml team want to be in charge of an LSP implementation for sysml that will be used everywhere else? Or leave this to the community to figure out? And if a community solution does emerge, will this community support be part of the Pilot implementations? Will the Pilot implementations have LSP/tree-sitter support?

Thank you all for listening to my thoughts and I appreciate the discourse!

@dadada
Copy link

dadada commented Jun 27, 2024 •
edited
Loading

I've been working on and off for the last few months on a tree-sitter parser for KerML/SysML with the goal of eventually open-sourcing it. So far it can parse and highlight some syntax such as comments, features, classifiers, namespaces, and so on. There is a small test corpus for that and some queries. Limited support for code navigation is also available via tree-sitter locals. What is left is to support all of the syntax and increase the size of the test corpus. It would be great if we could make this a community effort.

@acxz
Copy link
Author

acxz commented Jun 28, 2024

That's absolutely amazing @dadada! Do you have an idea on when you would open-source it or open it up to community contributions? Is there a roadmap for your project? Maybe a table with the syntax of the language as specified in the docs here, compared to existing parsing capability in your tree-sitter implementation?

I'm not familiar with tree-sitter locals, are you referring to anything mentioned on tree-sitter/code-navigation-systems?

@dadada
Copy link

dadada commented Jun 28, 2024 •
edited
Loading

Is there a roadmap for your project?

No, not so far. Would you be interested in contributing to the project, or know of others that might be interested? I'd like to avoid releasing a half-baked version.

I'm not familiar with tree-sitter locals, are you referring to anything mentioned on tree-sitter/code-navigation-systems?

Yes, I am trying to add support for both local.* queries and for tag-based queries.

@acxz
Copy link
Author

acxz commented Jul 3, 2024

I'd like to avoid releasing a half-baked version.

I understand and fully support that.

I won't be able to dedicate any substantial resources, but if you have bite size issues, I'd love to help tackle them. Unfortunately, I'm not aware of anyone else that would be interested.

Realistically, the lsp and tree-sitter impl for sysml should be incorporated into the pilot implementations. I would feel much better, if say the main contributors of the pilot implementations (@seidewitz, @himi, @hpdekoning, etc.) would give confirmation that they would consider a PR that adds lsp/tree-sitter support to the pilot implementations. It seems that @himi would be on board, from replies earlier in this thread.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@himi @dadada @acxz @hpdekoning