New favorite tool 😍

  • thingsiplay@beehaw.org
    link
    fedilink
    arrow-up
    8
    ·
    7 months ago

    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@programming.dev
      link
      fedilink
      arrow-up
      4
      ·
      edit-2
      7 months ago

      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.

      • thingsiplay@beehaw.org
        link
        fedilink
        arrow-up
        1
        ·
        7 months ago

        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@programming.dev
          link
          fedilink
          arrow-up
          2
          ·
          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”.