[Feature] Succeeded keyword

[Sod-Almighty]

In the examples on the website, I notice unsafe is being used in situations where a Bash command succeeding should cause a bailout condition. For example:

silent unsafe $ iwgetid -r | grep -E '(OEBB|WESTlan)' $
if status == 0 {
  echo "Skipping updates because of slow Wifi"
  exit(0)
}

When a failure should cause a bailout, you just use the failed keyword like this:

$mv file.txt dest.txt$ failed {
  echo "It seems that the file.txt does not exist"
}

There are only two script examples on the website, and both of them use unsafe to get around a limitation in Amber. If "failure is success and success is failure" situations are that common, why not have a keyword for it?

$ iwgetid -r | grep -E '(OEBB|WESTlan)' $ succeeded {
  echo "Skipping updates because of slow Wifi"
  exit(0)
}

[Sod-Almighty]

Perhaps also introduce a !? operator to complement the ? operator...

[b1ek]

i think we should get rid of the failed and use if for consistency in non-assignment situations

like this:

if $do_stuff$ {
    // succeeded
} else {
    // failed
}

if $do_stuff$ { // error!! no unsafe keyword or else block

}

let a = silent $get_a$ failed {
    0
}

[Ph0enixKM]

i think we should get rid of the failed and use if for consistency in non-assignment situations

like this:

if $do_stuff$ {
    // succeeded
} else {
    // failed
}

if $do_stuff$ { // error!! no unsafe keyword or else block

}

I’m afraid that this would introduce disambiguation for the if statement as the command evaluates to Text.

I like the succeeded but I’d go even further and introduce a match block that will match success, error or any custom code

[b1ek]

match block that will match success, error or any custom code

it would also be useful to work with variables, like to match different string constants. it probably could also be compiled to readable case ... esac

[Ph0enixKM]

it would also be useful to work with variables, like to match different string constants. it probably could also be compiled to readable case ... esac

Yes. That would be an interesting feature to add.

[Ph0enixKM]

If we do this - we could rewrite unsafe and silent command modifiers to be blocks:

block unsafe(command: Text) {
    ${command}$ failed {}
}

block silent(command: Text) {
    ${command} > /dev/null 2>&1$?
}

[Sod-Almighty]

Was this response intended to be posted on the "block" issue?

But yes....if we allow blocks to be invoked like modifiers:

pub block sudo(...) {
}

sudo $ thing $            // modifier syntax
sudo {
   $ thing $                  // block syntax
}

You mentioned macros.....would it be better for block functions to take an array of tokens instead of one big string?

pub block sudo(args: string array) {
   echo args[1]          // "mv"
   echo args[2]         // "thing"
}

pub fun move(file1, file2) {
  $ mv {file1} {file2} $
}

sudo move "thing" "otherthing"

[Ph0enixKM]

Yes it was. Sorry for the lack of context. I’ll think about it also from the compiler stand point and propose the ultimate solution to this. I like what you have shown better. The macros kind of syntax