4 ms·

Even low-level languages would struggle to get rid of "if"; any conditional branch is pretty much an "if". The various attempts in these comments to define "if

Even low-level languages would struggle to get rid of "if"; any conditional branch is pretty much an "if". The various attempts in these comments to define "if" in terms of lambda calculus or pattern matching or whatever are noble, but at the end of the day, they'll be running on actual computers and will boil down to conditional branches - a.k.a. "if" - and even when they ain't, they're still just fancier ways of saying "if" anyway. You can, however, do away with else using unconditional branches - a.k.a. "goto". Pseudocode: goto :positive if input > 0 goto :negative if input < 0 print "Got zero" goto :end :positive print "Got a positive number" goto :end :negative print "Got a negative number" :end Whether this is an improvement is questionable, but I've seen some industrial and enterprise systems with their own "graphical" languages that do this. I've also seen (in similar environments) the inverse where everything is an if/else (or pass/fail), like so: start: compare(input > 0) pass: positive fail: next : compare(input < 0) pass: negative fail: next : out("Got zero") pass: end fail: end positive: out("Got positive") pass: end fail: end negative: out("Got negative") pass: end fail: end end: exit() pass: next fail: next

revskill 4y ago
I think it's possible to design such language. My idea is, wrap an expression, then calculate if it's false then automatically try catch.
- yellowapple 4y ago
  The "calculate if it's false" is still an "if", though. At the end of the day it's still a conditional jump. The only way I see about avoiding that is by having the language target a "MOV machine" - that is, one where the only possible operation is to move values to/from memory. Conditionals would then work by writing values to predetermined addresses, reading a result from some predetermined address, and writing that result into the instruction pointer. This is cheating, of course (you've only punted the "if"s to the machine itself), and I wouldn't exactly call it "high-level", but it does technically satisfy the criterion of the language itself having no concept of a conditional jump (so long as it remains blissfully unaware of what the addresses it's reading/writing actually mean).

revskill 4y ago

I think it's possible to design such language. My idea is, wrap an expression, then calculate if it's false then automatically try catch.

yellowapple 4y ago
The "calculate if it's false" is still an "if", though. At the end of the day it's still a conditional jump. The only way I see about avoiding that is by having the language target a "MOV machine" - that is, one where the only possible operation is to move values to/from memory. Conditionals would then work by writing values to predetermined addresses, reading a result from some predetermined address, and writing that result into the instruction pointer. This is cheating, of course (you've only punted the "if"s to the machine itself), and I wouldn't exactly call it "high-level", but it does technically satisfy the criterion of the language itself having no concept of a conditional jump (so long as it remains blissfully unaware of what the addresses it's reading/writing actually mean).