Open Sod-Almighty opened 1 month ago
Perhaps also introduce a !?
operator to complement the ?
operator...
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
}
i think we should get rid of the
failed
and useif
for consistency in non-assignment situationslike 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
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
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.
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$?
}
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"
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
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:When a failure should cause a bailout, you just use the
failed
keyword like this: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?