As the /ONLY debacle was chipped away at... slowly... the role of quoting came to the forefront. Quotes were used to suppress splicing (in contrast with today's isotopic blocks through SPREAD, which request the splicing).
So the anti-spread behavior looked something like:
>> append [a b c] first [[d e]]
== [a b c d e]
>> append [a b c] first ['[d e]]
== [a b c [d e]]
I'm picking out of an outer block there just to avoid confusion, because notice what happens when there's no container:
>> append [a b c] [d e]
== [a b c d e]
>> append [a b c] '[d e]
== [a b c d e]
By design, the evaluator strips off quotes, leading to potential confusion when it comes to what people might think they could do with such a system.
You might think that this is all fine and you could just call the function QUOTE instead of putting a quote mark on the value. Hence the quoted block is an evaluation product not an evaluation input...and so it makes it to the append:
>> append [a b c] [d e]
== [a b c d e]
>> append [a b c] quote [d e]
== [a b c [d e]]
But there were protections that were added to try and discern if you were adding non-inert values without quoting them.
>> append [a b c] "this was presumed okay since it was inert"
== [a b c "this was presumed okay since it was inert"]
>> append [a b c] 'd
** Error: d is a WORD! and evaluative...your callsite might accidentally lose an
apostrophe if you didn't know what you were doing. Quote it to be safe.
(Note: I always disliked how these errors were working, I just hadn't gotten to the isotope design yet. They did afford some protection.)
This would lead you to a couple of bad options to work with the case when you had something evalutative at source level:
>> append [a b c] quote 'd
== [a b c d]
>> append [a b c] ''d
== [a b c d]
In an attempt to make the "just add a thing at source level" case a slight bit easier, I made JUST.
>> just d
== 'd
>> append [a b c] just d
== [a b c d]
Let's Take A Moment To Be Thankful For Isotopes...
All of this is behind us now.
But of course, the mechanics are actually nearly identical. Just subtract 1 from all the quoting levels, and allow -1 for BLOCK!s. (Then build upon years of diligence in bulletproofing the system from leaking -1 quotelevels where they shouldn't be.)
But JUST is Free Again. Now What?
There was a time when JUST was what I now call THE.
>> just x
== x
>> just ''[foo]
== ''[foo]
I thought it was a good word for it at the time. But THE won me over:
>> the x
== x
>> the ''[foo]
== ''[foo]
Maybe Something That Limits to One Expression Only?
>> just add 1 2
== 3
>> just add 1 2 10
** FAIL: JUST code had residual material: 10
I've been wanting a syntax for this at the API level, when you think you're running one expression:
REBVAL* sum = rebJust("add", value1, value2, "10");
In that world, it's not any more typing (actually less typing than rebValue)...but gives you an extra bit of safety.
With regular (non-API) code, I can see it being very useful in generated code scenarios.
Perhaps A THE-like Operator With A Shade of Meaning In PARSE?
PARSE needs to keep raw material sometimes, and I've pointed out some of the hazards in the past of making you do this with GROUP!s when nested compositions are involved.
So might these be different? As an example:
parse ... [x: the ''foo] => parse ... [x: (the ''foo)]
parse ... [x: just ''foo] => parse ... [x: '''foo]
So above, THE is synthesizing ''foo out of whole cloth with no need to match it in the input. The other would require a ''foo in the input to be considered a match.
For WORD!s, the above sense of JUST isn't as necessary, as there's a decent visual trick:
parse ... [x: just ''foo] => parse ... [x: '|''foo|]
But other datatypes would not have this out, and you'd always be reading the thing you see in the rule as having one more quote level than what you're matching.
There's the option of putting it in an @ group:
parse ... [x: just ''foo] => parse ... [x: @(the ''foo)]
But this has the problems I mention about nested composition that can be a major hassle when writing rule genreators and you have to weasel something like ''foo inside a group inside a composed block.
This definition might jibe with keeping the regular evaluator meaning of JUST as it is (literal but add a quoting level).
Other Ideas?
Hopefully no one wants to fight to swap JUST with THE, because I really like THE as it is.