Why No-Argument Refinements Are ~okay~ or ~null~

Development Functions
1

In Rebol2, a refinement's value would be #[true] or #[none]:

rebol2>> show-me: func [/bar] [print mold bar]

rebol2>> show-me/bar
true  ; actually LOGIC! #[true], not the WORD! true

rebol2>> foo
none  ; actually a NONE! value, not the WORD! none

As a newbie, I was bothered by this from the get-go... because I couldn't test refinements with AND/OR. (they don't take #[none]) I hadn't drank the Kool-Aid that ANY/ALL were always a desirable substitute.

NOTE: I never drank the ANY/ALL supremacy Kool-Aid. Of course there are a lot of cool uses for them as larger scale control structures--and it's important to know how to use them for streamlining program flow. But for testing flags? The ability to do it infix and without delimiters can read much better in many places.

So Ren-C has adopted infix AND/OR that operate conditionally on ANY-VALUE! and return LOGIC! (they also short-circuit)

ren-c>> flag1: flag2: true

ren-c>> if flag1 and flag2 [print "It allows WORD!s, this comes up often"]
It allows WORD!s, this comes up often

ren-c>> if all [flag1 flag2] [print "Not everyone loves this (e.g. not me)"]
Not everyone loves this (e.g. not me)

ren-c>> if (block? flag1) and (empty? flag1) [print "Short-circuit avoids error"]
; to do this, the second argument to AND/OR is quoted behind the scenes

There were countless debates over whether refinements should just be LOGIC! (as in Red), or if a used refinement should be the WORD! of the refinement (maybe useful for chaining?). For a time, it seemed murkier when Ren-C introduced NULL...although it all tied up rather nicely in the end!

Evolution Led Ren-C to Refinements As Their Own Arguments

  • Multiple-refinement arguments were a fringe feature, used almost nowhere. Primarily it just created an inconvenience for 1-argument refinements having to come up with some random name for the argument.

  • With the existence of antiform NULL, a single argument could represent the state of being used or not, along with the value itself.

    • The "used" state would be able to hold any non-antiform value (anything that can be put in a block)

    • NULL became a "branch inhibitor"--so just testing it with IF could cover most "is the refinement used" questions

    • All non-antiform values (and the antiform of ~okay~) eventually became branch triggers

      • This solved all the issues of conflating unused refinements with used ones that were things like BLANK! or the WORD! of FALSE

  • It simplified the evaluator logic--removing the "refinements pick up every parameter after them" semantic.

    • This paved the way for adding more arguments to functions after-the-fact, without worrying about them getting lumped in with the arguments of the existing last refinement.

But What About Refinements That Don't Take Arguments?

This question malingered along longer than I would have liked it to. :zombie:

For some time it would give you back a WORD! that was the name of the refinement itself:

old-renc>> show-me: func [/bar] [print mold bar]

old-renc>> show-me/bar
bar

old-renc>> foo
== ~null~  ; anti

I'd advocated for this idea very early on:

  • Imagine if one function took /only and wrapped another function that also took an /only

  • If the wrapper got its ONLY variable for the refinement as the WORD! only...

    • you could just say inner-function/(only)

      • If you got the refinement, that acts like inner-function/('only)

      • If you didn't get the refinement, that would act like inner-function/(null)

  • If you squint your eyes and use your imagination a little, this might seem like a useful tool for chaining.

But the feature was a victim of Ren-C's other successes. It's much easier and more efficient to wrap functions with things like ADAPT, ENCLOSE, SPECIALIZE. The need to write this kind of "tunneling" function is rare: and refinement naming overlap is unlikely if the functions weren't somehow derived from each other.

(It also made building FRAME!s at a low-level more annoying...the value you put in the frames had to be contingent on the refinement name. And it forced path dispatch steps to permit NULLs, when it didn't allow it anywhere else. More complexity, for little benefit.)

"Wouldn't LOGIC! For Argless Refinements be... Logical?"

You might think so. :robot: But actually... no.

Even before the design of Flexible Logic (where FALSE can't be tested for by a raw IF), it didn't make sense.

An intuitive angle might be to consider how an argument-less refinement contrasts with a refinement that takes an actual LOGIC! argument.

foo: func [/mutate [logic!]] [...]

This refinement can be NULL (unspecified--e.g. the refinement was not used at all), or #[true] or #[false] when it is specified. There's three states.

But an argument-less refinement is really just "used or unused". So NULL and then a single truthy state... ideally a state that the system understands as meaning "I'm opting in".

The Modern Day: ~NULL~ or ~OKAY~

OKAY is a branch-triggering antiform that exists as the complement to NULL.

>> 10 > 20
== ~null~  ; anti

>> 10 < 20
== ~okay~  ; anti

It's the perfect choice for an argless refinement.

>> f: make frame! :some-function
 
>> f.argless-refinement: x = y  ; slot will be null or okay
1 Like
5

(Note: Lifted this writeup out of another thread that otherwise is useless.)

Note that Ren-C had undergone hard-fought battles to confront problems like:

rebol2>> foo: func [/ref arg] [print ["ref:" mold ref "arg:" mold arg]]

rebol2>> foo
ref: none arg: none

rebol2>> foo/ref <thing>
ref: true arg: <thing>

rebol2>> foo/ref none
ref: true arg: none

rebol2>> condition: false
rebol2>> foo/ref if condition [<thing>]
ref: true arg: none

The above pattern made it hard for function authors to know if a refinement was in use. If they tried to go by the arg, they could be ignoring an inconsistent meaning where the caller literally meant to specify a none. The situation gets worse with multiple refinement arguments.

(Think about a case where you allow arbitrary values to be interleaved into a block with an /INTERLEAVE refinement, but no values will be inserted if the refinement is not intended. NONE! is one of the legal values, since it can be anything. If the function author heeds the refinement by name, then looks at the argument to see if there's a NONE!, it will work. But that prevents them from using the argument's status as none or not. The situation is confusing and you'd find functions making ad-hoc policy decisions, which may-or-may-not allow you to pass none as a way of backing out of a refinement when you used the refinement on the callsite.)

Gradually, the evaluator was made to keep the refinements' truth or falsehood in sync with the state of the arguments. Use of a NULL for all of a refinement's arguments at the callsite would make the refinement appear unused to the function, as if the caller had never specified it. Using NULL for only some of them would raise an error. And refinement arguments were never allowed to be themselves NULL... they were only nulled when the refinement was unused, and hence trying to access them would be an error.

This ultimately streamlined even further into the unification of the refinement and the argument itself...reducing the number of random words you'd have to come up with, shrinking call frames, eliminating a "gearshift" in the evaluator that opened doors to AUGMENT-ing frames with new normal arguments after a refinement argument.

But something to point out is that because these changes were incremental over time, ideas like the necessity of erroring on null accesses were also something that had to be challenged over time. I had a bit of uneasiness about things like:

rebol2>> foreach [x y] [1 2 3] [
             print ["x is" x "and y is" y]
         ]

x is 1 and y is 2
x is 3 and y is none

Something about running off of the edge of the data and not raising so much as a peep was unsetting. Doubly so because a NONE! might have actually been literally in the array. It seemed that once you had the power of NULL to distinguish, that not taking advantage of that with error checking would be a waste...

But such checks have upsides and downsides. Look at R3-Alpha:

r3-alpha>> data: [#[none!] #[unset!] 1020]
== [none unset! 1020]

r3-alpha>> data/1                          
== none

r3-alpha>> data/2  ; Note: prints nothing in console (and no newline)
r3-alpha>> data/3
== 1020

r3-alpha>> data/4
== none

Here's Ren-C:

>> data: [_ ~ 1020]
== [_ ~ 1020]

>> data.1
== _

>> data.2
== ~

>> data.3
== 1020

>> data.4
; null

Is this so bad, not to error on data.4 or other null cases? At least a distinct state is being signaled...that you can tell is out of band of what's in a block.

I think that when all angles are examined about how things have progressed, this makes sense, as does the unused-refinements-are-null change. It may feel a little more unsafe, but if we're using JavaScript...

js>> var data = [null]  // can't put undefined in array literal...
js>> data.push(undefined)  // ...but you can push it (?)
js>> data.push(1020)

js>> data
(3) [null, undefined, 1020]

js>> data[0]
null

js>> data[1]
undefined

js>> data[2]
1020

>> data[3]  // out of bounds (fourth element, indices are 0-based)
undefined

I think Ren-C is leading the way here, and that it's not worth getting bent out of shape over NULL accesses not triggering errors. The TRY mechanisms are there to pick up the slack when there are questionable uses of a NULL, to make sure it was intended.

1 Like