Soft Quoted Branching: Light, Elegant, Fast

It's uncommon to use expressions that evaluate to branches passed to conditionals. And when you do use one, you probably don't mind putting it in a GROUP! (especially considering that 99% of the time in the far more common cases you were willing to put it in a BLOCK!).

So Ren-C now uses that fact--plus generalized quoting--to allow for a briefer and faster way to evaluate to literals in your conditionals:

>> if true '[block as data]
== [block as data]

Simply pass in a QUOTED! item of any kind, and that item will be what a branch evaluates to. It will be one less level of quoting than what you pass in:

>> if true '<tag>
== <tag>

Previous attempts to get something like this used an /ONLY refinement. But this lets you mix and match in the same operator, as opposed to switching the operator into a "mode":

>> either true '[1 + 2] [1 + 2]
== [1 + 2]

>> either false '[1 + 2] [1 + 2]
== 3

It Solves Some Problems for CASE

Historically, CASE was more lax in accepting types than the corresponding IFs would be:

>> case [1 = 1 <foo>]
== <foo>

It would allow the by-products of arbitrary evaluation to be used:

>> word: <foo>
>> case [1 = 1 word]
== <foo>

Sometimes this resulted in double-evaluation:

>> word: [print "surprise"]
>> case [1 = 1 word]
surprise
== true

The dodgy nature of this "may be a double evaluation, may be not" with no way to tell at source level raised some concerns, which are laid out in the "backpedaling on non-block branches" post.

The combination of soft quoting and generalized quoting lets the same patterns that work for IF work in CASE. It lowers the risks in a legible way:

>> case [1 = 1 '<foo>]
== <foo>

It's Faster and More Efficient

Quoting is done with a byte in cells. So you can count up to 254 levels of quoting without really costing anything. (If you're wondering why not 255 levels since a byte can be from 0..255, it's because 255 is reserved for "isotopes".)

So '[x] costs less storage (and has better locality with the surrounding cells) than [[x]].

Outside of the reduced storage, it's also lighter on the evaluator, because it doesn't have to push an evaluator frame to run the block!

The consequences

There were very few pieces of code in the Ren-C repo that were affected. One was a help test. It wanted to generate a real-world block to run, and didn't want to call DO for some reason:

for-each w words of lib [
    dump w
    if not set? w [continue]
    if action? get w
        compose [help (w)]   ; errors now...IF thinks the COMPOSE word! is branch
    else [
        help (get w)
    ]
]

It's easy enough to change that to (compose [help (w)])...this kind of usage is very rare.

The one common case of passing code to a conditional originated from Ren-C...the use of lambdas that could take the argument of what drove the conditional:

 trap [1 / 0] then error -> [print [error]]

So you have to put it in a GROUP!:

 trap [1 / 0] then (error -> [print [error]])

I'm pretty sure this can be rethought to work as before, given the strategy of "right quoting always wins". But the evaluator has some kind of strict horse-blinder rules that guide its design, so not all things are possible. We'll see.

UPDATE 2020: The required rules have been implemented, and hard quoted left parameters on the right win in this instance, so the group is not necessary. :sushi:

Even if it couldn't get fixed, in the scheme of things it's worth it. And it isn't like people aren't used to putting branches in delimiters for blocks anyway!

1 Like

Here's another great argument for soft quoted branches:

>> 1 + either true [2] [3] + 4
== 7

>> 1 + either false [2] [3] + 4
== 8

If you try that in Rebol2 or Red, you get:

red> 1 + either true [2] [3] + 4
** Script Error: + does not allow block! for its value1 argument

In Ren-C you can even use IF/ELSE interchangeably with EITHER. (This interchangeability now works 99% of the time, so long as you're not trying to get a NULL result out of your truthy branch--nulls will be voidified)

 >> 1 + if true [2] else [3] + 4
 == 7

 >> 1 + if false [2] else [3] + 4
 == 8

This might point to using soft quoting for more things in the system where you think it is infrequent that people will be passing constructed meta-code in.

>> 1 + switch type of #x [issue! [2] tag! [3]] + 4
;-- wouldn't it be nice if this were 7?

It's a bit touchy-feely to make that call. You don't want to have to say compose (reduce [...]) instead of just compose reduce [...], but you're looking to get a block out of it. How many evaluative infix operators want a block out of their left hand side? I think if your construct is explicitly used in meta-coding, you want to bias it to fitting in with other meta-coding without needing to put arguments in groups.

But things like CASE and SWITCH might benefit from soft-quoting their case lists and switch lists, to favor the idea of fitting into more evaluative scenarios for using their product. While not being "a branch" per se, their lists are a kind of a "proxy for branches".

1 Like

So-called "soft-quoted branching" now runs up against the question of quoting's meaning for binding.

Generally we would assume the example above would mean you would get an unbound block (or, more accurately, the block with the binding it has... which is usually nothing if it's source).

This means it's semantically different from:

if true [[block as data]]

Because there, the block is evaluated... and under that evaluation, receives the current binding.

It would instead be the equivalent of:

if true ['[block as data]]

We can now consider the potential meaning of:

if true @[block as data]

This could be the real equivalent of if true [[block as data]].

@ forms aren't available for all types the way quoted forms are, but have the curiously appropriate property (in the current model) that they are available for all bindable types... so we can imagine the meaning of @ branches being "as is, bound".

This replaces a previous behavior of the @ types when used as branches, which was for words and tuples to substitute their values:

>> ae: 1020

>> if true @ae
== 1020

There wasn't any great logic to this, just the idea of "hm, what could that be for". Giving back as-is bound forms is a reasonable alternative--if this is deemed a useful thing to allow for branches.

1 Like