3 ms·

I find that the assumption that program control requires boolean values (of any kind) facinating, since there are at least two languages that use success/failur

I find that the assumption that program control requires boolean values (of any kind) facinating, since there are at least two languages that use success/failure as the controlling mechanism - Snobol (in all its incarnations) with the follow up language of Icon/UnIcon. Neither have the concept of booleans, but use the idea that a computation can succeed and return a result or fail and return no result. This leads to making certain kinds of expressions that normally require booleans and the associated logical operators to be simpler and more clear, as below: if a < b && b < c && c < d then ... compared with if a < b < c < d then .... Which is easier to mentally parse?

cpeterso 9y ago
I really liked how Icon handles function success/failure separately from return values. It seems very close to Go's error handling conventions, but with a little more magic. Wikipedia gives the following Icon example code: if a := read() then write(a) which would translate into something like the following Go code: a, err := read() if err == nil { write(a) }
- oldandtired 9y ago
  Simplify this to write(a := read()) where write will not be executed if read fails, nor will a have any value assigned to it. Failure is an option and not an error. So to copy standard input to standard output, we do every write(read()) At the end of file, the read fails, the write fails and then the every fails and on you go.