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.
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?
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. :-/
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 TRY is aiming to be used in error management.
>> 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
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 [ ].