Move stdlib to the client machine rather than being compiled in

[b1ek]

reciting @KrosFire :

For the LSP I need std lib files on the client machine, and not as a part of the compiler.

@KrosFire can you please explain what is exactly the problem with LSP and if there is any workaround possible without moving stdlib to the host filesystem?

[Mte90]

Prrobably because the LSP need to read the std files to share this information.
Maybe we can do that amber with a parameter return the stdfiles of that build in a stdout?

[Mte90]

Or another solution is that the LSP is bundled for a specific Amber version and that include the specific std.

[b1ek]

i think that only @KrosFire could answer this accurately

[KrosFire]

It's required to correctly show the definition of stdlib functions in any given IDE. Just like you can see how the stdin function looks in rust imported from std, or any other language that has some libraries.

Holding every library file as a part of amber binary is giving unnecessary bloat to a binary

[KrosFire]

Go to definition request response can only be a link to a file. If the file doesn't exist, it won't work. LSP server shouldn't be installing stdlib that should be installed with the compiler. And while installing LSP via an addon in some IDE, user shouldn't be giving permissions to create some scripts in some obscure locations

https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#location

[Mte90]

I understand as it is common with LSP server to have stub files for frameworks and libraries that those tools index to have those information internally.

Looking like the other does the LSP embed internally those references for the native stubs. So I suggest that every LSP release is specific for a amber version, or another option give to the LSP a way to update the stdlib.

[Ph0enixKM]

So the only good solution here is to bundle stdlib with the compiler. Every modern programming language does this. There are two ways that I see we can handle this:

1. Bundling the files in the installer (in the tar file that we pull from the releases)
2. Shipping just the compiler (nothing changes in the CI) but when the compiler is first run - it pulls the standard library from the GitHub release and sets it up

[b1ek]

i think that if we decide to separate it away from the compiler, we should really go for it:

• move stdlib to be maintained independently from the compiler in a separate repository
• have a package loader in the compiler that could load 3rd party libraries with the same mechanism it uses for stdlib

[b1ek]

by a package loader i mean something like it is implemented in node:

• it resolves package names to ./node_modules/$name and /usr/lib/node_modules/$name and some other paths
• it doesn't manage packages, that is done by 3rd party package managers like npm and yarn
• • like integrity checks, dependency resolution, etc