Chapter: Background - #2
Conversation
|
Uploaded preview of this chapter and the full document preview branch Preview: chapter/background |
1 similar comment
|
Uploaded preview of this chapter and the full document preview branch Preview: chapter/background |
|
|
||
|
|
||
| ## Data oriented languages | ||
|
|
There was a problem hiding this comment.
What about transformations/term level handling of contracts and recursinve records etc.
Especially contracts as they get rewritten into expressions run during runtime.
I think this concept applies better to the background as I dont use it in the LSP, yet it is quite technical/internal.
| ### Software defined Networks | ||
| ### Software Networks | ||
|
|
||
|
|
There was a problem hiding this comment.
Should i go into detail of things like parsing and AST construction here as well?
There was a problem hiding this comment.
I imagine you have to say somewhere the following: traditionally, programs are parsed as an AST (explaining quickly what it is). However, for the LSP, we need to enrich this data structure (while not polluting the core nickel implementation) and we need to index things by positions. Those two constraints explain your technical choices.
There was a problem hiding this comment.
I think i will motivate the need for enriching the AST (and in short describing what is the AST) in #4 or otherwise move the Nickel AST section from Method to Background entirely
b32e9c0 to
70e2aec
Compare
|
Uploaded preview of this chapter and the full document preview branch Preview: chapter/background |
1 similar comment
|
Uploaded preview of this chapter and the full document preview branch Preview: chapter/background |
|
|
||
| ## Language Server Protocol | ||
|
|
||
| ### Rationale |
There was a problem hiding this comment.
Discuss use-cases as part of related work (on other usecases such as dsl's)
|
|
||
| ### Rationale | ||
|
|
||
| Since its release, the LSP has grown to be supported by a multitude of languages and editors[@langservers @lsp-website]. |
There was a problem hiding this comment.
General question: footnotes or refernces for websites
|
Uploaded preview of this chapter and the full document preview branch Preview: chapter/background |
5 similar comments
|
Uploaded preview of this chapter and the full document preview branch Preview: chapter/background |
|
Uploaded preview of this chapter and the full document preview branch Preview: chapter/background |
|
Uploaded preview of this chapter and the full document preview branch Preview: chapter/background |
|
Uploaded preview of this chapter and the full document preview branch Preview: chapter/background |
|
Uploaded preview of this chapter and the full document preview branch Preview: chapter/background |
| `"jsonrpc" : "2.0"` | ||
| ~ A fixed value format indicator | ||
|
|
||
| `"method"` | ||
| ~ The name of the procedure called on the server | ||
| ~ May not start with `rpc.` which is an indicator for internal messages | ||
|
|
||
| `"params"` | ||
| ~ An optional set of parameters passed to the executed method. | ||
| ~ Parameters can be passed as a list of arguments or as a named dictionary. | ||
|
|
||
| `"id"` | ||
| ~ A (unique) identifier for the current message | ||
| ~ Used to answer client requests | ||
| ~ Messages without an `id` are considered to be *Notifications* |
There was a problem hiding this comment.
I feel like this key specific documentation and the following prosa are somewhat redundant.
I'm not sure which to keep, especially considering my comment on documenting the LSP
There was a problem hiding this comment.
I think you can get rid of this indeed. You can link to the LSP official documentation somewhere. Explaining a few things like below is fine, but reproducing technical documentation is a bit superfluous.
There was a problem hiding this comment.
I think about turning the schema into a short example, just to have an idea at least
Something like
{ "jsonrpc": "2.0", "method": "add" , "params": [1,2] , "id": 12 }There was a problem hiding this comment.
Yes, short examples are always welcome
|
Uploaded preview of this chapter and the full document preview branch Preview: chapter/background |
3 similar comments
|
Uploaded preview of this chapter and the full document preview branch Preview: chapter/background |
|
Uploaded preview of this chapter and the full document preview branch Preview: chapter/background |
|
Uploaded preview of this chapter and the full document preview branch Preview: chapter/background |
|
|
||
| ## Configuration programming languages | ||
|
|
||
| Nickel [@nickel], the language targeted by the language server detailed in this thesis, defines itself as "configuration language" used to automize the generation of static configuration files. |
There was a problem hiding this comment.
This section describes the use-case for text based configuration files, their shortcomings in terms of validation and language features.
I then mention using general purpose languages for configuration, closing with why one would want to use configuration programming languages
| Despite this, not all languages serve as a configuration language, e.g. compiled languages and some domains require language agnostic formats. | ||
| For particularly complex products, both language independence and advanced features are desirable. |
There was a problem hiding this comment.
Mention the security aspects of using an evaluated language with access to the system?
There was a problem hiding this comment.
You can mention it. Most of the config languages I know and you cite are pure, that is they can't perform side effects like interacting with the system. It's an important property for both reproducibility (avoid having the configuration unseemly depends on external state) and security (you don't want your config to be able to run arbitrary programs).
There was a problem hiding this comment.
Secure also in terms of leaving critical holes in a network which could solve statically checked or enforced against using contracts
There was a problem hiding this comment.
also Chef uses ruby ...
And in the end this would be an argument for DSL like languages with certain restrictions
|
Uploaded preview of this chapter and the full document preview branch Preview: chapter/background |
| Language servers are today's standard of integrating support for programming languages into code editors. | ||
| Initially developed by Microsoft for the use with their polyglot editor Visual Studio Code^[https://code.visualstudio.com/] before being released to the public in 2016 by Microsoft, RedHat and Codeenvy, the LSP decouples language analysis and provision of IDE-like features from the environment used to write. | ||
| Developed under open source license on GitHub^[https://github.com/microsoft/language-server-protocol/], it allows developers of editors and languages to work independently on the support for new languages. | ||
| If supported by both server and client, the LSP now supports more than 24 language features^[https://microsoft.github.io/language-server-protocol/specifications/specification-current/] including code completion, hover information, resolution of type and variable definitions, controlling document highlighting, formatting and more. |
There was a problem hiding this comment.
"If supported by both server and client": I don't understand the logical relation between this beginning and the rest of the sentence.
There was a problem hiding this comment.
Well, implementing language features on the server side does not mean these are available on your editor and vice versa.
In fact both declare sets capabilities.
All 24 features are only available for a combination of editors (clients) and servers that support them all
| Applications of configuration languages are ubiquitous especially in the vicinity of software development. While XML and JSON are often used by package managers [@npm, @maven, @composer], YAML is a popular choice for complex configurations such as CI/CD pipelines [@travis, @ghaction, @gitlab-runner] or machine configurations in software defined networks such as Kubernetes and docker compose. | ||
|
|
||
| Such static formats are used due to some significant advantages compared to other formats. | ||
| Most strikingly, the textual representation allows inspection of a configuration without the need of a separate tool but a text editor and be version controlled using VCS software like Git. |
There was a problem hiding this comment.
You explain why text configuration is better than some random proprietary format + a GUI application to control it. I would also insist in this paragraph on why configuration has become so ubiquitous recently: infrastructure as code and related paradigms. That is, configuration is replacing a lot of things that were done in an imperative manner formerly. Sysadmins 20 years ago were mostly linux users typing commands on servers. Nowadays they are mostly SRE/DevOps writing yaml and deploying through things Kubernetes/docker/Terraform. I don't think you would use Nickel for an npm package description (it would probably be overkill, and here simplicity is a good thing). One important motivation for Nickel is all these new use-cases for configuration that just didn't exist before, and they bring in complexity. There, JSON and co becomes verbose, hard to maintain, hard to "debug", and so on.
The first symptom is you ending up duplicating a lot of data that may become out of sync (like IPs, machine names, servers, etc.). Just by adding variables (let-binding) and say string interpolation, you already gain a lot by being able to specifying a single source of truth and refers to it elsewhere. With functions, you are able to describe dependencies between data: typically, the list of open ports is derived from the list of enabled protocols, e.g.
There was a problem hiding this comment.
That's covered in parts in another subsection
| Despite this, not all languages serve as a configuration language, e.g. compiled languages and some domains require language agnostic formats. | ||
| For particularly complex products, both language independence and advanced features are desirable. |
There was a problem hiding this comment.
You can mention it. Most of the config languages I know and you cite are pure, that is they can't perform side effects like interacting with the system. It's an important property for both reproducibility (avoid having the configuration unseemly depends on external state) and security (you don't want your config to be able to run arbitrary programs).
| Alternatively to generating configurations using high level languages, this demand is addressed by more domain specific languages. | ||
| Dhall [@dhall], Cue [@cue] or jsonnet [@jsonnet] are such intermediate languages, that offer varying support for string interpolation, (strict) typing, functions and validation. | ||
|
|
||
| ## Infrastructure as Code |
There was a problem hiding this comment.
Oh you intend to have a specific section dedicated to this. Then I would put this section before the previous one, as it serves as context about why configuration languages are needed. IaC is one of the main motivation and use-case.
| For particularly complex products, both language independence and advanced features are desirable. | ||
| Alternatively to generating configurations using high level languages, this demand is addressed by more domain specific languages. | ||
| Dhall [@dhall], Cue [@cue] or jsonnet [@jsonnet] are such intermediate languages, that offer varying support for string interpolation, (strict) typing, functions and validation. | ||
|
|
There was a problem hiding this comment.
You should probably also cite Nix, as it is one of the main target of Nickel. Don't have to explain everything, but mention it is a package manager enforcing reproducibility that uses a language to describe its software packages.
|
Uploaded preview of this chapter and the full document preview branch Preview: chapter/background |
3 similar comments
|
Uploaded preview of this chapter and the full document preview branch Preview: chapter/background |
|
Uploaded preview of this chapter and the full document preview branch Preview: chapter/background |
|
Uploaded preview of this chapter and the full document preview branch Preview: chapter/background |
|
@yannham I addressed most of your remarks, if you want to have an eye on it |
Co-authored-by: Martin Monperrus <martin.monperrus@gnieh.org>
Co-authored-by: Martin Monperrus <martin.monperrus@gnieh.org>
Co-authored-by: Martin Monperrus <martin.monperrus@gnieh.org>
Co-authored-by: Martin Monperrus <martin.monperrus@gnieh.org>
(cherry picked from commit 4c3c83c)
2 participants
Uh oh!
There was an error while loading. Please reload this page.