What amber is

[b1ek]

we should figure out what amber is, and/or wants to be.

there have been already a few problems because there isn't a clear definition of exactly what goals does amber has, mainly about runtime dependencies.

so, there are a few questions that need answering so that we could actually know what it is that we are building:

1. are we doing strict or loose typing?
2. should a user be able to run it everywhere or we save up the generated code size and development time (don't implement everything in bash/amber)?
3. which bash version do we target?
4. should the compiler be used directly by the user or via a manager like cargo or clang?
   1. if it should be used by a manager like cargo, that would mean we would be adding a lot of CLI arguments and then some higher level program will wrap it nicely in a config file or something

i have probably missed a few more important questions, so either edit the post to add them or comment them down

[b1ek]

i feel like we shouldn't optimize for portability. it will obviously be nice to have, but not with bash's limitations. as well as we just don't have enough brain power to work around every possible aspect in bash.

we are going to need to either build our own runtime binary library thingy or depend on a hell lot of shit (like jq and bc)

[arapower]

I had the same issue as @b1ek .

If I were to add a question, it would be the following:

• Should we consider compatibility with sh instead of just bash?

Personally, I think it's better to reduce the dependency on external commands as much as possible and simplify Amber.
I think it would be better to enrich the ecosystem for writing scripts with Amber.

In addition to that, we could prepare a separate Amber extension library.
For example, by specifying a Git repository with import, it can be incorporated into the generated shell script.
The dependency on each extension library can be determined by the user individually.
If we make such an assumption, I think it would be possible to maintain compatibility with sh.

[b1ek]

its important that reducing dependency on external commands has a cost, which is:

1. you can just forget about script readibility
2. it is basically bloatware since its not shared with other amber scripts - imagine if a system has installed 10 amber programs and each one of them has a bundled in runtime library which takes 100~1000kb per script
3. some things are just not exactly possible to implement in bash alone. dictionary-like objects are a prime example of that

what we could do is to make two modes: basic and extended, where basic amber is just a nice wrapper around bash that has no runtime, and extended has more advanced features like classes and stuff.

[arapower]

The most important thing I want to emphasize is whether there are plans to provide shell scripts compatible with sh.

There have been several people who have requested compatibility with sh. I am one of them.

From here on, I will give my personal opinion, but please bear with me.

What they ultimately want is a shell script compatible with sh.
Because they have to run their programs in a limited environment such as a lightweight container.

And they probably don't want a highly functional shell script.
They are probably attracted to the ecosystem that Amber provides, which increases safety, such as data types.

They probably won't require all functions currently implemented in Amber to be compatible with sh.
They just want Amber to generate shell scripts that run in sh as an option.

Therefore, I think it is fine to treat functions that cannot be used in sh, such as arrays, as errors when generating sh-compatible shell scripts.

If Amber becomes able to generate sh-compatible shell scripts, I will modify the functions to be written in a sh-compatible way.
If the sh-compatible syntax is too complicated to be accepted, I'll give up on including it in Amber and implement it in an external library myself.
That is, if the functionality of the external library is implemented.

I don't mind if the generated sh-compatible shell script doesn't depend on the runtime when executed.

[Mte90]

• I think that should be strict in this way is more portable and more safer, I think that as first goal can be generate a Bash code that is fine for shellcheck
• It should be able to run it everywhere based on the builtin stuff and std, so if we do a download function we should have some fallbacks for the various commands
  • This means maybe check if on OSX commands are different (I know that sed has some different parameters)
  • At same time just for the stuff that is shipped natively, for other everyone will do compatibility layers
• The most used? Or the latest? I think that as the first goal is enough to be compatible with Bash and maybe when the project is more solid add the others like sh.

[Ph0enixKM]

@b1ek @arapower @Mte90

1. Amber was build with progressive typing in mind. The user is in control of how much typed they want to write a script. Small scripts could be too small to force developers to use types everywhere. Big scripts could benefit from the fact that you can type everything.
2. I think it should run on many even small environments where Bash is typically used too. We could actually build that Amber runtime in Go to easily cross compile it and ship it for other people. I think that runtime should be a part of Amber project and should be versioned like the compiler or else we could end up having a total mess of incompatibility when old Amber 0.5.2-alpha script tries to fetch the newest stable runtime from the github releases and fails, because a lot has changed.
3. I think that max 3.0 so that we can support macOS as well. In the (near) future we could just support sh and only rely on the runtime... which would be really cool and more future proof. For a stable release I think that we should go this route.
4. I feel like for now the amber should be treated like the full package. I think that we have to iterate a bit to see whether we need to pivot and build something external i.e. "the manager"

To be honest I don't see Amber to work at all with a ton of dependency commands. We need to build a one runtime that can work with Amber. The only problem will be to handle permissions and where to store the runtimes. Perhaps we will build the runtime installer into an Amber script that will ask the questions if the person wants to download the Amber runtime installer and where shall it be stored.

[Mte90]

If we do a binary embedded inside the Bash script I think that people will prefer other languages at all at that point.

[Ph0enixKM]

We'd also have to answer this question:

[b1ek]

is it really the script's responsibility to download the thing? i'd either make a runtime install script (like the already existing compiler installer) or let the system package manager handle that

[Ph0enixKM]

This should be a discussion instead of an issue. Converting.

[FedericoCeratto]

My use case for Amber is:

• generate sh/bash scripts in a significantly safer way
• ...using a more friendly syntax
• ...that are still readable and tweakable enough in [ba]sh format in order not to force all users to use Amber
• to be used for the same use cases as shell scripts: glue code, execution of commands, system administration tasks
• shipped in popular Linux distributions

[FedericoCeratto]

I would also add what is not a priority for my Amber use case: CPU and memory efficiency (otherwise I would use Rust), object orientation, functional programming, anything that would make the generate shell script big e.g. exceptions, stacktracing

[FedericoCeratto]

I think it would make sense to make the target slightly modular:

• For simpler scripts pure sh is the most portable option. (Plus it can be significantly faster when interpreters like dash are used)
• For complex scripts with arrays and hashmaps it could require Bash 4
• Dependencies on bc, sed, jq etc can be easily made optional

A little pragma at the beginning of an Amber file can enable each option. Using a function that requires a disabled option triggers a compile error and a friendly message e.g.

The use of `arctan` requires the `bc` tool. Enable it with `options: bc` at the top of myscript.ab

Related to #95 #219 #66

[Ph0enixKM]

Okay so I'll update this conversation here with what was decided on our Discord server:

The proposition:

• Move any use of external binary from the language itself to a stdlib. I'm looking at bc, sed and seq. We can write some wrappers for them. The exception could be Num - it'd be implemented with fixed decimal representation (7 as an example) of numbers should be good enough.

• Introduce the sh compatibility mode so that users can squish the portability out of the Amber script to maximum. For me the portability part seems like a big value proposition that I don't want to miss.

• We don't use any hacky ways to implement complex data structures for bash in older versions. If user wants maximum compatibility - they can run amber with sh flag turned on. If user wants robustness - they could compile to bash.

Amber will not:

• Implement JSON or any other complex data type that doesn't exist in Bash out of the box (on the language level)
• Implement features that are hard to be implemented in regular Bash (besides Num)
• be an OOP language as it's not the best solution for scripting and automations (we can always implement something that fits our needs)

[Ph0enixKM]

Why Amber?

Amber is a next step in making the shell scripting more accessible and more maintainable. It's foundation is to solve the problems that couldn't be solved with just Bash and too clunky to use Bash library for.

I think that it would lower the bar to enter Linux ecosystem and make is easier to organise and maintain scripts. Furthermore I believe that Amber will improve the developer experience when writing scripts that manage necessary workflows.

For example developers with different shell scripting skill levels could operate on the same Amber project maintaining the readability and security by preventing many accidental bugs by keeping the shell code in the spotlight for code reviewers that is always contained between dollar symbols.

Amber is meant to be portable, safe, modern, predictable and readable.