I have, on and off, wondered whether IF should do a trick like the loops are doing now, where if a branch is taken then the result is forced to a BLANK!. So even if print "Hi" has a void result, an x: if true [print "Hi"] sets x to BLANK!. This way, you would be able to use void to determine that the branch was not taken.

If this pattern were applied uniformly, then ELSE could just be an infix operation that evaluates its left and if it's void, runs the code on its right. You could say switch thing [blah [...] blah [...]] else [...]...basically any construct that could come back as a void could have an else clause.

This is an example of where ELSE would thus want a non tight evaluation of its left hand side.

This appeals to me because the "brancher" logic is not only more complex, it's more costly...you have to generate a function, and then call the function. This is inexpensive, easier to understand, and means you don't have to put in a "/?" switch on all the control constructs... you can write them all as e.g. if?: chain [:if | :any-value?]

@rghris @MarkI @Brett @giuliolunati --^ ?

The downside is that you can't easily bubble a void out of a conditional expression, and the most common example of that would be something like x: if condition [:y], where you are trying to mirror the value of a variable into another one based on a condition, and you think of "unsetness" as being in that range. There's likely not much legacy code that looks like that, because x: () was illegal until Ren-C.

else: enfix adapt 'unless [condition: any-value? :condition]... that's... pretty cool. When I compare this idea to all the cruft used to implement branchers and such today, and the generality, it seems a pretty big win.

Some progress. My app is now detected by Amazon Echo as a Philips hue bridge, and I can control my lights on/off using voice and rebol :)

So, now instead of lights, I can control any device using voice that has a simple tcp/udp interface.

I haven't seen Carl's video for a long time but I think he had an Insteon serial modem so that he could control using a serial protocol on a USB port. The insteon serial modem then converts the commands to whatever protocol it uses.

@GrahamChiu Very nice.

For a more complicated work I can use Alexa to send commands by IFTTT which I can parse out and do whatever

@GrahamChiu ^-- what do you think of the above, not being able to propagate a void (unset) out of a branch from a conditional, but it getting "blankified"? Then voids can signal that the conditional didn't get taken...whether it's a CASE, SWITCH, IF, etc.

Too late for me .. can't process all that text

This would hurt stuff like compose [blah (case [a [do stuff ()] b [do stuff fill in stuff]]) blah blah]... e.g. if you wanted to do some processing yet still wanted to have some of your cases signal an opt-out. But as long as you're willing to use blank for that, you could say opt case [...]; it just means you couldn't literally place a blank in. I think this is a fine tradeoff.

Oh, one thing that used to work with ELSE breaks this way. case [thing1 [stuff1] thing2 [stuff2] else [stuff3] thing4 [stuff4]]. That used to let you say that stuff3 would run if it got as far as skipping the thing2 case, yet continue running cases.

heh, I didn't even know case had an ELSE

Am I the only person here with an Echo??

@GrahamChiu :-P

I think I must be in with the retro crowd here :(

@GrahamChiu CASE didn't have an ELSE, that's sort of the trick of the ELSE as infix operator. Although you might argue case "did have an else" since it spoke a protocol of "branchers".

Now that's going away, but I'm going to miss being able to put code in mid-CASE to say "if you got this far in the cases, run some code, then keep matching"

You can do it with case [a [b] (stuff to run | false) [] c [d] e [f]], but that's ugly.

But overall, I think the balance needs to keep pushing toward that goal of simple with large force multiplier. There's a big difference between invasively asking every construct that does something "branch-like" (whatever that means) to consider either a block or a function as a candidate and maybe pass that function a LOGIC! if it's arity 1... vs. just saying "make your construct return void if you didn't do anything"

Though if you write foo: func [condition x] [either condition [bar x] [baz x]] you wind up losing information if bar or baz return voids. :-( This is a little trickier; it's information loss when you are dealing with functions that are black boxes. I think this black-box scenario is what discouraged me from trying to tamper with branches in the past.

One answer, which I think might be a good answer, would be if procedures don't return void, but they return BLANK!. This would mean that voids falling out of branches would be uncommon enough that you wouldn't really care if you said foo: if x [:some-var] else [:other-var] and some-var was void, so it wound up taking what other-var returned. That might even be what you want.

This means EITHER and IF-ELSE would not be technically equivalent, which isn't necessarily the end of the world as long as people understand there's no such thing as "IF-ELSE"... just IF and ELSE. You can even write either condition [x] [y] else [z], and if whichever branch is taken winds up being void you still run the else. You could also chain as many elses as you want.

else meaning <-if-that-full-expression-is-void-run-this-block [...]

Well, it's a bigger deal than that, because you could say if condition1 [if condition2 [...]] else [...], and then a false condition2 would mean you'd get a void branch and run the else clause. I don't think this is the end of the world, though. It seems to me actually that reimagining ELSE to be more generically meaningful is a better idea than breaking the pass-thru logic of all the conditionals.

You could just say if? condition1 [if condition2 [...]] else [...] and that solves it.

>> if? true [print "Hello"] else? [print "Goodbye"]
Hello
== false

>> if? false [print "Hello"] else? [print "Goodbye"]
Goodbye
== true