THEN and ELSE are Essential

[hostilefork]

When I was describing the details of rigging it so enfix functions could interoperate with multiple retrun values, @iArnold responded:

@iArnold

@hostilefork

But How Does IF Know ELSE Wanted The /BRANCHED Output?
ELSE runs after IF. So it would need to be able to connect its need for a branched output up to IF's parameterization before IF runs.

This problem was solved in R2. IF knew there was no else and EITHER did.

Rather than just delete and ignore this tangent... I'm moving it here with another remark from Chris:

@rgchris

I should say that as of now, I don't have a favourable opinion of the ELSE/THEN idiom (on a stylistic/comprehension basis) and don't think they're worth the extra complexity alone

Let me respond quickly.

I Haven't Given Up Making It Not Affect Those Who Don't Use It

Firstly: You should always have the last resort of using Redbol if you want, and I'm trying my best to make sure every convention is reversible. Though it's a bit of a hard pill to swallow to dial back large parts of the language a decade, I think it can be done in something of a piecemeal way so that you can revert just the parts you don't like.

Secondly: As the post I made shows, I'm still racking my brain to see what I can do, even if it means pretty crazy evaluator acrobatics. If my current trick manages to pan out, there will be a generic mechanism for getting more than one value across an enfix call barrier. It would mean all branches would go back to being "as-is". But who knows what other doors might open.

ELSE and THEN are Bigger Than An Alternative To EITHER

I've demonstrated the synergy between CASE and SWITCH and ELSE and ALSO and THEN. When you throw invisibles like ELIDE in, you get evaluator combinatorics I have never seen before. Expressing imperative logic with so many seamless "asides" is going to be a real mind-blower.

This is what makes the language worth paying attention to. If I'm impressed, then that's a pretty high bar, and so I shouldn't be the last person to feel that way.

(Quite a stronger and more timeless message than "fastest mostly-open-source 32-bit Rebol2 on Earth".)

Remember The Self-Selection Bias

If you have been using Rebol for decades, and see no problem with forcing every IF...ELSE to be EITHER, remember this:

you are one of a very, very small minority of people who managed to not be put off by the language

Maybe my tastes are "mainstream". But I don't usually like EITHER. It might fit in sometimes when I can get everything all on one line.

But since I still use other languages besides Rebol, I haven't forgotten that the straightforward ordinary way can be coherent and nice:

 if ((a and b) or (c and d)) { ... } else { ... }

Which makes you see just how uncomfortable this is:

either any [all [a b] all [c d]] [ ... ] [ ... ]

I'm more than intelligent enough to understand both. And with years to consider it, I still prefer the first if those were my only two options. Though I might like to write that particular one as:

any [a and b, c and d] then [ ... ] else [ ... ]
      ; ^-- I'm considering AND's quoting convention to allow WORD!s on right

Of course, how you look at it depends on the length of the clauses and what you're going to emphasize. If you've got enough code to warrant newlines, the ANYs and ALLs start being better propositions.

But on a higher level: if you're advertising "most freeform programming language ever invented", saying that you "have to write your code in a style you don't like much, because it's Rebolish" is missing the message.

THEN, ELSE, and ALSO are Non-Negotiables for Me

I've pointed out before that the illusion of this is what keeps me going:

@hostilefork

I think every time we get another one of these illusions under our belt, like ELSE and THEN, the game goes a little further. I'd have quit Rebol a long time ago if these breakthroughs weren't still coming along... each one probably buys one more month of my interest in the area of study

I'd quit if this stuff weren't in the mechanics, because the language wouldn't interest me much.

[iArnold]

Maybe I did, did just not understand what you meant completely. Or I did completely not understand at all.
Possible.
Sure appreciate that the old way will be supported. Sure appreciate your interest in pushing the limits on the language forward. And I cannot blame you for striving to make it your worthwhile in the process.
Many times I really wonder, when to use the new features, as I kind of think most are probably esoteric or pathologic in nature, use cases I rarely will encounter in my daily wishes for places where the computer could help out in making life easier for me. And certainly when the new features are starting to look like regexes I seriously doubt my use of those.
So please keep up the good work and make this beautiful gem of a language even more capable to do even the impossible. And do take my remarks as if they are coming from Mars.

[hostilefork]

@iArnold

Many times I really wonder, when to use the new features, as I kind of think most are probably esoteric or pathologic in nature

The best thing is to show code you have, and ask if it could be made better or clearer by means of a change. I can offer suggestions.

If over time you notice that learning the new tools makes things better, then it wouldn't seem esoteric.

@iArnold

And certainly when the new features are starting to look like regexes

Don't know what features you mean.

[BlackATTR]

This is a terrific post, and a good reminder (although some may see it as a warning). Self-selection indeed-- that is exactly the phenomena at play here.

Also, I use this construct in the majority of my scripts:

@hostilefork

either any [all [a b] all [c d]] [ ... ] [ ... ]

And in my biased opinion: It. Sucks.

Readability over writability.

[rgchris]

This is an attempt to enumerate my aversion to THEN/ELSE, it's my first pass so it may not capture all of my considerations.

I primarily use ] and ][ as scanning mechanism for where code continues/ends.

either any [
    a and b
    c and d
][
    ...
][
    ...
]

This flow is broken by THEN/ELSE:

any [
    a and b
    c and d
] then [
    ...
] else [
    ...
]

Not only is the flow broken, but one must be mindful that the original proposition (ANY) my not end the current expression. That precludes THEN/ELSE on a new line (which depending on the density of code within the expressions, may utilize an additional new line for clarity):

any [
    a and b
    c and d
]

then [
    ...
]

else [
    ...
]

The above might have some merit in code folding in text editors.

If the argument is which looks better on a single line—I could see that as an advantage in small statements:

color: provided-color else [default-color]

However, as soon as this started to get noisy, I would start to break it out.

---

I'm sympathetic to considering the perspective of what makes people comfortable coming from other languages, however I'd prefer to be driven by what the best idiom is for this language and how that aids comprehension when sharing code in that language.

[hostilefork]

@rgchris

I'm sympathetic to considering the perspective of what makes people comfortable coming from other languages, however I'd prefer to be driven by what the best idiom is for this language and how that aids comprehension when sharing code in that language.

I disagree pretty thoroughly. But don't mind your perspective, and so I want to make sure you can write code how you want to, even if I wouldn't do it that way. So let's focus on you being able to do things the way you want to.