[Feature] Numbers and arbitrary precison

[davekeogh]

https://github.com/Ph0enixKM/Amber/blob/eedd6812c06885b8d1658c6b19246238bff7e489/src/translate/compute.rs#L51

I understand that bash cannot handle arbitrary precision numbers, but I think many users may prefer a low precision mode that does not generate pipelines like this.

There may also be an issue of bc not being installed on all systems.

[orent]

While bc is available on regular desktop linux environments it is missing in many "lite" cloud environments. It is not acceptable to rely on it, especially without checking at the top of the generated script to fail fast with a suitable warning.

In general, anything that can be done with bash builtins without forking an external command should be done with builtins e.g. variable expansion substitutions instead of sed, case/esac globs, etc. Even if it is awkward, the performance difference is huge.

Also, check all generated code with ShellSheck.net.

[Ph0enixKM]

Yeah, At first I wanted to make Amber feel more JavaScriptish so I decided to use the bc everywhere. However this creates a limitation and dependency on the bc command. The solution would be to introduce a new integer datatype Int that is a lightweight alternative.

[garyrob]

I just want to chime in that I agree about having an Int datatype that doesn't require bc. I was looking for something that compiled to bash so that I could make some software I'm thinking about distributing as easy to install and run as possible. Requiring cloud linux users to install bc just to run my software defeats the purpose. And I won't have need of anything beyond what an Int datatype would offer. I expect that's true for many potential projects that could otherwise use Amber.

[eXamadeus]

@Ph0enixKM there is a conversation happening on your reddit post related to this link. I'd like to say that I'm a big fan of a new integer type, as it would resolve to much "cleaner" integer comparisons.

In regards to needing bc for lots of operations, I'm not sure you'll be able to easily get around the requirement for things like floats/etc. In fact, I'm fairly certain bash only natively supports integer comparisons. So people are generally used to needing to use bc for complex math calculations. Those that don't have bc available are usually not needing to perform such arithmetic (this is a big assumption on my part, mind you).

---

An interesting approach you could take, that would allow for the complete removal of bc, would be to allow "fixed precision arithmetic" that uses integer math to get decimal results. In this example (taken from StackOverflow) you can see how it's possible to use integers to do basic arithmetic for fixed-precision results (in this case 2 decimal positions):

VALUE=100
DIV=3
RESULT=$((${VALUE}00/$DIV))
echo "${RESULT:0:-2}.${RESULT: -2}"
33.33

This would obviously be a large and rather complex change. You could come up with a "scale" that is generally available for floating-point math. Something like 6 decimals would probably suffice, and any more precision would be up to the users to figure out (they can do the same integer math, if they so desire). Granted this is assuming a lot and definitely makes maintenance of the language much more challenging.

The easiest approach would be to simply say "we don't support floating point arithmetic" and use only bash, leaving it to the user to figure out their own floating point solutions. This is actually the most "stable" approach IMO and will leave any generated output as close to pure bash as possible. This may, however, deviate wildy from your original vision of "JavaScript-like".

[Ph0enixKM]

@eXamadeus Thank you for your point of view. I also think that we need to pivot the vision a little and simply add the Integer type to Amber. The closer we can get to readable bash, the easier it will be to read and debug!

[nicktimko]

95 mentions checking for sed, [[ and bc, but [[ IIRC is specifically a Bash-ism.

Looking at some Docker images like amazonlinux and ubuntu, they include sed but not bc.

The alpine image doesn't include Bash, but it does seem to have [[ in it's BusyBox executable...maybe for some limited cross-compatibility?

In general though, compiling to Bash is nice because it would provide some good bootstrapping capabilities, and might be all you need. My interpretation for Amber's niche in that using Bash-as-a-target, it can be used in very minimal environments, and ideally down to zero in some cases. For instance, to configure some environment you could load your compiled .ab and go. If there's a hard requirement on some deps, you'll need to load some .sh which might need to configure proxies and set up the environment before apt/yum/apk even works, so you're needing to bootstrap a bootstrap script, but then you could just bootstrap Python which can take you even further.

Crappy ASCII diagram

                 Environments
 Simpler                                Richer
<---------------------------------------------->
^ base alpine
|    ^ base ubuntu, amazonlinux, debian
|    |         ^ base desktop Linuxes
|    |         |
X========== shell scripts
     |  =======X======== single-file Python or similar
     |         |  ======================== Ansible/Salt/Puppet/etc.
   [-?-]=======X=== Amber?
<---------------------------------------------->
Simple Tasks                           Whatever
                 Ideal for...

[Ph0enixKM]

95 mentions checking for sed, [[ and bc, but [[ IIRC is specifically a Bash-ism. Looking at some Docker images like amazonlinux and ubuntu, they include sed but not bc.

The solution would be the following: If Num is never used anywhere, then the compiler will not include the bc dependency in the bootstrap. This would extend the scope of Amber for simpler environments.

[Mte90]

Closed as duplicates for https://github.com/amber-lang/amber/issues/70

[Ph0enixKM]

@Mte90 this is #70

[Mte90]

So https://github.com/amber-lang/amber/pull/381 tries to remove sed to clean up numbers and use the scale variable for echo that defines the approximation and the behavior with results.

Maybe it is the first step...