Runtime engine

[b1ek]

as the project grows, it will use more and more bash code to add more features.

obviously its not a very good thing to bundle everything into a single bash file, especially when its not necessary.

i propose this: by default, an amber program will check if amber runtime library is installed in /usr/lib/amber/runtime.sh and import everything from there to make the compiled script more readable and smaller in size.

the problem with this approach is that amber becomes less portable by definition. i think it could be made portable by using some sort of bash bundler, heck we could probably even write our own, its not that complicated.

[b1ek]

also it could probably pull the runtime library from github if it is not installed

[b1ek]

just to be clear, im not talking about the stdlib. im talking about language features, such as objects

[Ph0enixKM]

I was thinking about exactly the same thing but to make the runtime compiled. The language could pull it from the github if not detected. The main advantage is that it would run fast. The main disadvantage is that we'd support only 4 targets for now probably - macOS x86 & ARM and Linux x86 & ARM.

The binary would also enable us to setup some simple HTTP server in Amber if needed and other cool things.

[arapower]

I think extensions to Amber itself would be welcome if they did not affect compiled shell scripts.

Assuming that such enhancements were not made, will there be any plans to add more architectures in the future?

[Ph0enixKM]

Sure. We have 2 options here.

1. Create runtime.sh that can be sourced. It will be the most cross platform although more limited than using a binary.
2. Create amb (a small compiled Amber runtime). It will be somewhat cross platform (we'd add more and more arch support as we move on). It will be essentially a switch to turn on true programming language power

I'd honestly lean on the 2nd option.

[Ph0enixKM]

I'm converting this issue to a discussion as this requires more explanations and details.