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

🔣 A domain-specific language with handler combinators #186

Open
favonia opened this issue Nov 1, 2024 · 4 comments
Open

🔣 A domain-specific language with handler combinators #186

favonia opened this issue Nov 1, 2024 · 4 comments

Comments

@favonia
Copy link
Contributor

favonia commented Nov 1, 2024

  1. Dispatching diagnostics to different handlers
  2. Duplicating diagnostics to multiple handlers
  3. Filtering diagnostics
@kentookura
Copy link

I was going to write a response here that something like a handler combinator thingy is the more natural way to proceed, but you beat me to it :)

@favonia
Copy link
Contributor Author

favonia commented Nov 1, 2024

@kentookura Are you claiming that with these three combinators you can already implement the features you wanted trivially?

@kentookura
Copy link

Yes, I think so

@kentookura
Copy link

kentookura commented Nov 8, 2024

One thing that I want to point out is that when implementing a language server, it is important that an empty list of diagnostics gets pushed when a computation that previously failed now succeeded. Right now I am checking this manually, but maybe this is an interesting factor when designing this.

Another thing is that diagnostics need a URI to be published to, and a computation might raise diagnostics for many files. I am handling this by

  • making sure that all diagnostic loctexts get created with the source argument
  • accumulating them in a (Lsp.Uri.t, diagnostic list) Hashtbl.t that gets populated by emit and fatal: I am inspecting the loctext of the diagnostic and creating an Lsp.Uri.t from it.

This is not enough, though:
Say that evaluating file A previously failed and had a diagnostic pushed to it. Running the evaluator again now succeeds, but now I need to know that A failed the last time in order to push an empty list to clear the diagnostics, so I need to track some state.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants