this post was submitted on 21 May 2024
206 points (96.4% liked)

Programming

17669 readers
171 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]



founded 2 years ago
MODERATORS
 

New favorite tool ๐Ÿ˜

you are viewing a single comment's thread
view the rest of the comments
[โ€“] zygo_histo_morpheus 52 points 7 months ago (4 children)

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?

[โ€“] [email protected] 35 points 7 months ago

Yeah that shit is completely unreadable

[โ€“] [email protected] 30 points 7 months ago* (last edited 7 months ago)

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).

[โ€“] [email protected] 16 points 7 months ago (1 children)

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.

[โ€“] BatmanAoD 12 points 7 months ago (1 children)

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.

[โ€“] [email protected] 8 points 7 months ago (1 children)

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.

[โ€“] BatmanAoD 4 points 7 months ago* (last edited 7 months ago) (1 children)

No, I mean, analyzing the Amber expression to determine if Bash has a native construct that supports it is unnecessary if all arithmetic is implemented using bc. bc is strictly more powerful than the arithmetic implemented in native Bash, so just rendering all arithmetic as bc invocations is simpler than rendering some with bc and some without.

Note, too, that in order to support Macs, the generated Bash code needs to be compatible with Bash v3.

[โ€“] [email protected] 1 points 7 months ago (1 children)

I see, it's a universal solution. But the produced code is not optimal in this case. I believe the Amber code SHOULD analyze it and decide if a more direct and simple code generation for Bash is possible. That is what I would expect from a compilers work. Otherwise the generated code becomes write only, not read only.

[โ€“] BatmanAoD 2 points 7 months ago

Compiled code is already effectively write-only. But I can imagine there being some efficiency gains in not always shelling out for arithmetic, so possibly that's a future improvement for the project.

That said, my reaction to this project overall is to wonder whether there are really very many situations in which it's more convenient to run a compiled Bash script than to run a compiled binary. I suppose the Bash has the advantage of being truly "compile once, run anywhere".

[โ€“] [email protected] 13 points 7 months ago

So many forks for something that can be solved entirely with bash inbuilts