Why does the generated bash look like that? Is this more safe somehow than a more straighforward bash if or does it just generate needlessly complicated bash?
I doubt the goal is to produce easily understood bash, otherwise you’d just write bash to begin with. It’s probably more similar to a typescript transpiler that takes in a language with different goals and outputs something the interpreter can execute quickly (no comment on how optimized this thing is).
Especially as Bash can do that anyway with if [ "${__0_age}" -lt18 ] as an example, and could be straight forward. Also Bash supports wildcard comparison, Regex comparison and can change variables with variable substitution as well. So using these feature would help in writing better Bash. The less readable output is expected though, for any code to code trans-compiler, its just not optimal in this case.
It’s probably just easier to do all arithmetic in bc so that there’s no need to analyze expressions for Bash support and have two separate arithmetic codegen paths.
But its the other way, not analyzing Bash code. The code is already known in Amber to be an expression, so converting it to Bash expression shouldn’t be like this I assume. This just looks unnecessary to me.
Looking at the example
Why does the generated bash look like that? Is this more safe somehow than a more straighforward bash if or does it just generate needlessly complicated bash?
Yeah that shit is completely unreadable
I doubt the goal is to produce easily understood bash, otherwise you’d just write bash to begin with. It’s probably more similar to a typescript transpiler that takes in a language with different goals and outputs something the interpreter can execute quickly (no comment on how optimized this thing is).
Especially as Bash can do that anyway with
if [ "${__0_age}" -lt 18 ]as an example, and could be straight forward. Also Bash supports wildcard comparison, Regex comparison and can change variables with variable substitution as well. So using these feature would help in writing better Bash. The less readable output is expected though, for any code to code trans-compiler, its just not optimal in this case.It’s probably just easier to do all arithmetic in
bcso that there’s no need to analyze expressions for Bash support and have two separate arithmetic codegen paths.But its the other way, not analyzing Bash code. The code is already known in Amber to be an expression, so converting it to Bash expression shouldn’t be like this I assume. This just looks unnecessary to me.
So many forks for something that can be solved entirely with bash inbuilts