If I've done my due diligence in reasoning through a world where NULL is normalized, then being able to have your code assert places where you didn't expect a NULL is pretty important.
>> must find "abc" "b" == "bc" >> must find "abc" "q" ** Error: MUST requires argument to not be NULL
Once upon a time, this was called ENSURE:
>> append x ensure select [a 10 b 20] 'c ** Error: e.g. "Couldn't ENSURE you had a value, it was NULL"" ** Near: ensure ** select [a 10 ... (blah blah
But that was retaken to be a 2-argument function: a variant of MATCH that triggers an error if the type doesn't match a type or set (e.g.
ensure [text! integer!] 1 + 2). It passes the value through if it matches, and raises an error if it does not.
I used that all the time, whereas a single-arity function that checked against NULL seemed less useful. So long as you were throwing in a check, was "it's not null" the only thing you knew about the data? You could even say ensure any-value! ... if that was the case, and that wasn't too bad.
Still...for the heck of it, I went ahead and made a non-null checker and called it... REALLY. Yes, REALLY.
>> append x really select [a 10 b 20] 'c ** Error: e.g. "You REALLY wanted a value, but got back NULL" ** Near: really ** select [a 10 ... (blah blah
I didn't like the name, and never used it. Nulls caused enough problems in those days on their own.
But with Sometimes-Too-Friendly Nulls, callsites could REALLY use this now.
I'd be willing to shuffle names around. But ENSURE became quite entrenched. I'd be loathe to retake it unless a quite good replacement were found.
So, what've we got?
Hm, wait... GOT?
I just wrote that and wondered if it could work:
>> append x got select [a 10 b 20] 'c ** Error: e.g. "Thought you GOT a value, but you got nothin' (it was NULL)" ** Near: got ** select [a 10 ... (blah blah
It's weird, and has a bit of that problem of looking at a word where it doesn't look like a word. Then none of them do if you think too much. Interesting term to know: "semantic satiation"
The idea that GOT is an assertion, a la "I got this", is certainly odd. My leaning is that maybe that suggests it's better as a version of GET that ensures the lookup was not NULL? Otherwise you'd wind up writing oddities like got get. :-/
So this may play a role here in code that wishes to be more cautious about NULLs, as really get. That phrasing makes REALLY look a bit favorable. :-/
TRY would be nice (but it's taken)
I wish we had a short name like TRY available. That would look good:
>> append x try select [a 10 b 20] 'c ** Error: e.g. "You TRY'd but did not succeed, and got a NULL" ** Near: try ** select [a 10 ... (blah blah
But right now it's what powers the "blank in, null out" convention that helps long chains of expressions optimize yet gives error locality. That's pretty solid stuff, IMO (quick recap):
>> data: [a [b 1]] >> select select data 'a 'b == 1 >> select select data 'x 'b ** Script Error: select requires series argument to not be null ** Near: [... select data 'x ~~ 'b] >> select try select data 'x 'b ; null
This fits into the angle of how NULL is still error-causing in many slots, and must be defused into blanks to be accepted in most parameters...(that aren't refinements!)
When it was an UNSET!=>NONE! converter, BrianH suggested TO-VALUE (which I independently proposed when I wanted the operation), and he also proposed DEFANG (weird, and also less appropriate in light of the premise here that NULL is fairly mild).
I don't know what decent name TRY could be pushed to in order to retake it. DENULL sucks. BLANKIFY sucks. REIFY is awfully grandiose.
What's nice about TRY here i.m.o. is how it reads at the callsite. You don't have to know that it turns nulls into blanks, you just sort of see it in a chain mitigating an error. There is MAYBE:
>> select maybe select data 'x 'b ; null
I don't like it as much for this, and think the MAYBE operation is a lot cooler for what it does right now.
DID would also be nice (but also taken)
>> append x did select [a 10 b 20] 'c ** Error: Thought you DID get a value, but you didn't, it was NULL ** Near: try ** select [a 10 ... (blah blah
DID is serving a good purpose as a complement to NOT, and I'm quite attached to it. It has also made it into the C sources (replacing the
We Never Figured Out The
Maybe this is common enough that the ? operator could be taken for it...
>> append x ? select [a 10 b 20] 'c ** Error: e.g. "Asked the big question 'are you a value?' and it wasn't" ** Near: ? ** select [a 10 ... (blah blah
Perhaps not... but it does raise the point that we are asking for sort of a general evaluator operation or something at the callsite to say "I don't want this to be a NULL, here". Maybe unicode or emoji... check mark?
>> append x ✓ select [a 10 b 20] 'c
In fact, just calling it CHECK is an option...though that sounds like something that would be more generic. Or VERIFY? Those sound awfully more grandiose and parameterized than simply seeing if something is null or not. But rebol's fluidity is about letting you name any of these things out of the way if you find them objectionable.
Anyway, REALLY isn't going to get used for anything else (at least no time soon) so it's not like it's hurting anything. I'm just afraid that if it's too gnarly to use that people won't get into the habit of supplementing their code with a nice annotation saying "I expect this to succeed".
The floor is open for thoughts. Short words preferred. Might this be the mysterious use for BE?
>> be 300 + 4 == 304 >> be "I'm an ANY-VALUE!, therefore I am." == "I'm an ANY-VALUE!, therefore I am."
Doesn't make as much sense at the callsite, though:
>> append x be select [a 10 b 20] 'c ** Script Error: e.g. "A NULL is nothing, and thus cannot BE" ** Near: be ** select [a 10 ... (blah blah
>> append x can select [a 10 b 20] 'c ** Script Error: e.g. "Thought you could get a non-NULL, but you COULDN'T" ** Near: can ** select [a 10 ... (blah blah
Problem being it sounds a little like a question word. append x can any [ ].
Another one I had wondered about was THE. Probably better than BE, but still a bit obtuse.
>> append x the select [a 10 b 20] 'c ** Script Error: e.g. "Can't use THE to refer to something that's not there" ** Near: the ** select [a 10 ... (blah blah >> y: null >> append x the y ** Script Error: e.g. "Can't use THE to refer to something that's not there" ** Near: the ** y
That's...maybe not objectively awful.