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!
But, 2022 UPDATE: I've cleaned up a bunch of historical rambling of me talking to myself in this thread to pare it down to what's useful.
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 non-valued 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-VALUE! that could be put in a block.
-
NULL became falsey--so just testing it with IF could cover most "is the refinement used" questions...with specific tests for NULL? when there was risk of conflation with BLANK! or 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.
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
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.)
So Wouldn't LOGIC! For Argless Refinements be... Logical?
You might think so. But actually... no.
There are a number of technical reasons. Yet 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 BLACKHOLE! (#)
While BLANK! has worked nicely as a falsey reified unit type, we've been lacking a truthy unit type.
But with the unification of issues and characters, the appealing truthy "kind-of-a-unit-type" of # exists. And its meaning of "please opt-in" is a good match for refinements.
- Space-wise fits in a single cell with no allocation, like BLANK!
- It's not a series so it's not mutable and has very few operations it responds to.
- It's one easily-visible character.
- And again, it is truthy.
Simple To Set, Doesn't Depend on the Refinement Name
>> f: make frame! :some-function
>> f.argless-refinement: if x = y [#] ; slot will be either null or #
First reflex might be to make a TO-BLACKHOLE or similar:
>> f.argless-refinement: to-blackhole x = y
But I actually think the if condition [#]
looks pretty nice. It's unambiguous and you get the idea. "check this box, else leave it empty". Short and obvious!
Blackholes Are Fit For Purpose, and Aligns With Multi-Returns
Blackholes were first invented to help "opt-in" scenarios with multi returns, with patterns like:
if multireturn-var [ ; request for additional work made
set multireturn-var do-additional-work
]
The truthy nature of #
, along with being a no-op with SET, made it easy to request the additional work be done while not needing to name a variable to store the output.
That's no longer needed in multi-return, because it proxies variables for you automatically, so you don't need the overhead of SET.
But it's still a useful feature, and can come in handy with # produced by used refinements!
Higher Level Functions Can Add Conveniences!
If you think it would be nice to be able to specify an argless refinement with a LOGIC!, guess what... you can! (Just not when building low-level frames...)
Higher level functions like APPLY are happy to turn a LOGIC! into a NULL or # for you.
>> apply :append [[a b c] [d e] /only 1 = 1]
== [a b c [d e]]
SPECIALIZE doesn't do it at time of writing, but maybe it should...
>> apo: specialize :append [only: 2 = 2]
** Script Error: Argless Refinement /only Must be either # or NULL
In any case, I just wanted to explain why an argless refinement to your function is going to be showing up as # or NULL, and that's more or less the final (?) answer.