search

Systems-Modeling / SysML-v2-Pilot-Implementation

Proof-of-concept pilot implementation of the SysML v2 textual notation and visualization
GNU Lesser General Public License v3.0
113 stars 23 forks source link

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

Open acxz opened 1 week ago

acxz commented 1 week ago

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 commented 1 week ago

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 commented 1 week ago

Akash,

I was just going to reply that Sensmetry’s SysIDE has implemented LSP support. It works very well in their VSCode deployment and provides an excellent start for more development. See also https://github.com/sensmetry/sysml-2ls/tree/main/packages/syside-languageserver .

As far as I understand the LSP approach is also considered in the SYSON project (https://github.com/eclipse-syson/syson).

Regards, Hans Peter

From: Akash Patel @.> Sent: Thursday, June 13, 2024 5:10 PM To: Systems-Modeling/SysML-v2-Pilot-Implementation @.> Cc: Subscribed @.***> Subject: Re: [Systems-Modeling/SysML-v2-Pilot-Implementation] Thoughts on language tooling? i.e. Language Server Protocol/tree-sitter (Issue #571)

It seems like Sensmetry may have a language server implementation with their SysIDE vscode pluginhttps://marketplace.visualstudio.com/items?itemName=sensmetry.sysml-2ls. However, their implementation is embedded within their pluginhttps://gitlab.com/sensmetry/public/sysml-2ls/-/issues/13 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.

— Reply to this email directly, view it on GitHubhttps://github.com/Systems-Modeling/SysML-v2-Pilot-Implementation/issues/571#issuecomment-2165957546, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AHY4GEDO3CI46MWS2YHSCFTZHGY3ZAVCNFSM6AAAAABJISITMKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRVHE2TONJUGY. You are receiving this because you are subscribed to this thread.Message ID: @.**@.>>

acxz commented 1 week ago

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 commented 1 week ago

Interesting topic. I want to use abstract syntax as well as concrete syntax for further model-aware processing. So I would like to use the LSP feature of xtext ( https://eclipse.dev/Xtext/documentation/340_lsp_support.html) and LSP4E ( https://projects.eclipse.org/projects/technology.lsp4e) However there seems no activity taking this approach so far. Maybe the SysON project takes a similar approach but unfortunately their metamodel is not the same with that of SysMLv2-Pilot-Implementation. So I'm wondering if I would need to seek some way. If it needs much development effort, I will simply use Lezer on CodeMirror for that purpose. LSP is fairly good but not so responsive and not so useful for advanced language processing.

With regards,

-- Hisashi Miyashita Mgnite Inc.

On Thu, Jun 13, 2024 at 11:17 AM Hans Peter de Koning < @.***> wrote:

Akash,

I was just going to reply that Sensmetry’s SysIDE has implemented LSP support. It works very well in their VSCode deployment and provides an excellent start for more development. See also https://github.com/sensmetry/sysml-2ls/tree/main/packages/syside-languageserver .

As far as I understand the LSP approach is also considered in the SYSON project (https://github.com/eclipse-syson/syson).

Regards, Hans Peter

From: Akash Patel @.> Sent: Thursday, June 13, 2024 5:10 PM To: Systems-Modeling/SysML-v2-Pilot-Implementation @.> Cc: Subscribed @.***> Subject: Re: [Systems-Modeling/SysML-v2-Pilot-Implementation] Thoughts on language tooling? i.e. Language Server Protocol/tree-sitter (Issue #571)

It seems like Sensmetry may have a language server implementation with their SysIDE vscode plugin< https://marketplace.visualstudio.com/items?itemName=sensmetry.sysml-2ls>. However, their implementation is embedded within their plugin< https://gitlab.com/sensmetry/public/sysml-2ls/-/issues/13> 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.

— Reply to this email directly, view it on GitHub< https://github.com/Systems-Modeling/SysML-v2-Pilot-Implementation/issues/571#issuecomment-2165957546>, or unsubscribe< https://github.com/notifications/unsubscribe-auth/AHY4GEDO3CI46MWS2YHSCFTZHGY3ZAVCNFSM6AAAAABJISITMKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRVHE2TONJUGY>.

You are receiving this because you are subscribed to this thread.Message ID: @.**@.>>

— Reply to this email directly, view it on GitHub https://github.com/Systems-Modeling/SysML-v2-Pilot-Implementation/issues/571#issuecomment-2165980778, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAACSKO47VOBUTUYQZHTHC3ZHGZZBAVCNFSM6AAAAABJISITMKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRVHE4DANZXHA . You are receiving this because you are subscribed to this thread.Message ID: <Systems-Modeling/SysML-v2-Pilot-Implementation/issues/571/2165980778@ github.com>

acxz commented 1 week ago

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 commented 1 week ago

Oh, I thought this discussion thread is on GitHub issues. Please use the SysML v2 Release https://groups.google.com/g/sysml-v2-release Google Group if you want to continue. It seems you understand most of my points. I can simply say that currently I'm not so interested in supporting various IDEs. Rather, I want to make an advanced intelligent SysMLv2 editor on top of SysMLv2 Pilot Implementation.

On Thu, Jun 13, 2024 at 12:13 PM Akash Patel @.***> wrote:

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 https://gitlab.com/sensmetry/public/sysml-2ls/-/issues/13)

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.

— Reply to this email directly, view it on GitHub https://github.com/Systems-Modeling/SysML-v2-Pilot-Implementation/issues/571#issuecomment-2166127781, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAACSKIY63A4EPZJRLFHN53ZHHAJJAVCNFSM6AAAAABJISITMKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRWGEZDONZYGE . You are receiving this because you commented.Message ID: <Systems-Modeling/SysML-v2-Pilot-Implementation/issues/571/2166127781@ github.com>

acxz commented 1 week ago

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!