Open katcipis opened 7 years ago
@tiago4orion we can even leave the multiple returns to implement later, this one is the only thing you will need to add some concurrency :-)
Ok, I just started implementing this.
What do you think about dropping the support of the '-cmd' syntax? This change is a good use-case for a fix
tool. Converting from:
-test $VAR "<" 10
if $status != "0" {
exit(1)
}
# inc
sum <= -expr $VAR "+" 1
if $status != "0" {
exit(1)
}
echo "sum is "+$sum
To the program below:
_, status <= test $VAR "<" 10
if $status != "0" {
exit(1)
}
# inc
sum, status <= expr $VAR "+" 1
if $status != "0" {
exit(1)
}
echo "sum is "+$sum
is very achievable with current nash parser library.
Another point, this improvement gives a safe way to enable shorter error handling in command execution in the same way Go does:
if output, status <= ./scripts/deploy.sh; $status != "0" {
printf "Deploy failed... Output: %s\n" $output
exit(1)
}
I'd avoided program execution inside if conditions because I wasn't aware of a good way of separating the command and the boolean condition. Implementing the syntax above, the second part of the if
must be a boolean condition, just like it works today.
@katcipis What do you think?
OMG, the:
if output, status <= ./scripts/deploy.sh; $status != "0" {
printf "Deploy failed... Output: %s\n" $output
exit(1)
}
Is FUCKING AWESOME.
But right now it just sink that it would good to have integers before all this, the status is clearly a integer...not a string. But changing would break a lot of stuff right ? =/
This:
Should work as a way to not abort if the command explodes, and stores the status of the command at the "status1" variable.
Functions behaviour can stay the same, and later we can add support to multiple returns, so this pattern can be applied to functions as well, although we do not wish to enforce any specific behavior on error handling for functions (good practices are welcomed)