4 ms·

If is semantically the only way to deconstruct a Boolean in any language, so as long as you have bools, you’re going to have `if`. Sure you can give if differen

by quchen 4y ago

If is semantically the only way to deconstruct a Boolean in any language, so as long as you have bools, you’re going to have `if`. Sure you can give if different syntax and write it with match/case/?:/whatever, but that’s not what we did to goto: introducing different language constructs to capture common useful use cases like try/catch, loops, and else-less ifs.

palotasb 4y ago
To nitpick and to show a cool lambda calculus thing, you can deconstruct booleans if you define booleans and if statements the following way, using only pure functions. def TRUE(a, b): return a def FALSE(a, b): return b def IF(cond, a, b): return cond(a, b) assert IF(TRUE, 1, 2) == 1 assert IF(FALSE, 1, 2) == 2 This gives you the conditional statement in most languages ("cond ? a : b" or "a if cond else b").
- quchen 4y ago
  Church encoding is pretty cool, yes! It encodes Booleans such that »if == id«. Likewise, natural numbers are essentially counting for-loops: 3 f x = f (f (f x)), so »for == id«. I had to work with this for a while because I wanted to implement Hello World in Javascript. https://github.com/quchen/lambda-ski/blob/master/helloworld/hello.js https://github.com/quchen/lambda-ski/blob/master/helloworld/...
- Joker_vD 4y ago
  You can do this same trick with any algebraic type, honestly (modulo lazyness): ## type Silly = Foo | Bar Int | Qux String Silly ## Constructors def Foo(onFoo, onBar, onQux): return onFoo() def Bar(arg0): return lambda onFoo, onBar, onQux: onBar(arg0) def Qux(arg0, arg1): return lambda onFoo, onBar, onQux: onQux(arg0, arg1) ## Values of Silly type are Foo, Bar(x) and Qux(x, y) ## Destructor def match_Silly(silly, onFoo, onBar, onQux): return silly(onFoo, onBar, onQux) You can make a whole language on top of that if you don't mind effectively disabling your CPU's branch predictor.
chriswarbo 4y ago
I agree; although there's a related problem of "boolean blindness" https://existentialtype.wordpress.com/2011/03/15/boolean-blindness https://existentialtype.wordpress.com/2011/03/15/boolean-bli... I'd summarise boolean blindness as: implicit (often unsafe) coupling/dependencies of method results; which could instead be explicit data dependencies. That article's example is 'plus x y = if x=Z then y else S(plus (pred x) y)', which uses an unsafe 'pred' call that crashes when x is 'Z'. It avoids the crash by branching on an 'x=Z' comparison. The alternative is to pattern-match on x, to get 'Z' or 'S x2'; hence avoiding the need for 'pred'. Another alternative is to have 'pred' return 'Maybe Nat'; although that's less useful when we have more constructors and more data (e.g. the 'NonEmptyList' in this "parse, don't validate" article!)
jakelazaroff 4y ago
There are concepts like filtering that let you operate on booleans without branching: const published = posts.filter(post => !post.draft);

by quchen 4y ago

palotasb 4y ago

To nitpick and to show a cool lambda calculus thing, you can deconstruct booleans if you define booleans and if statements the following way, using only pure functions. def TRUE(a, b): return a def FALSE(a, b): return b def IF(cond, a, b): return cond(a, b) assert IF(TRUE, 1, 2) == 1 assert IF(FALSE, 1, 2) == 2 This gives you the conditional statement in most languages ("cond ? a : b" or "a if cond else b").

quchen 4y ago
Church encoding is pretty cool, yes! It encodes Booleans such that »if == id«. Likewise, natural numbers are essentially counting for-loops: 3 f x = f (f (f x)), so »for == id«. I had to work with this for a while because I wanted to implement Hello World in Javascript. https://github.com/quchen/lambda-ski/blob/master/helloworld/hello.js https://github.com/quchen/lambda-ski/blob/master/helloworld/...
Joker_vD 4y ago
You can do this same trick with any algebraic type, honestly (modulo lazyness): ## type Silly = Foo | Bar Int | Qux String Silly ## Constructors def Foo(onFoo, onBar, onQux): return onFoo() def Bar(arg0): return lambda onFoo, onBar, onQux: onBar(arg0) def Qux(arg0, arg1): return lambda onFoo, onBar, onQux: onQux(arg0, arg1) ## Values of Silly type are Foo, Bar(x) and Qux(x, y) ## Destructor def match_Silly(silly, onFoo, onBar, onQux): return silly(onFoo, onBar, onQux) You can make a whole language on top of that if you don't mind effectively disabling your CPU's branch predictor.

chriswarbo 4y ago

I agree; although there's a related problem of "boolean blindness" https://existentialtype.wordpress.com/2011/03/15/boolean-blindness https://existentialtype.wordpress.com/2011/03/15/boolean-bli... I'd summarise boolean blindness as: implicit (often unsafe) coupling/dependencies of method results; which could instead be explicit data dependencies. That article's example is 'plus x y = if x=Z then y else S(plus (pred x) y)', which uses an unsafe 'pred' call that crashes when x is 'Z'. It avoids the crash by branching on an 'x=Z' comparison. The alternative is to pattern-match on x, to get 'Z' or 'S x2'; hence avoiding the need for 'pred'. Another alternative is to have 'pred' return 'Maybe Nat'; although that's less useful when we have more constructors and more data (e.g. the 'NonEmptyList' in this "parse, don't validate" article!)

jakelazaroff 4y ago

There are concepts like filtering that let you operate on booleans without branching: const published = posts.filter(post => !post.draft);