What to call the anti-DEFAULT?

DEFAULT exists to run a block of code to give something a value if it doesn't have one already.

 >> x: ~
 >> x: default [10 + 20]
 >> print x
 30

 >> x: <some-tag>
 >> x: default [10 + 20]
 >> print x
 <some-tag>

@gchiu at one time asked for an "anti-default". Rather than make the decision of whether to overwrite or not based on the content of the variable and only sometimes evaluate the block...always evaluate the block, then decide whether to overwrite or not based on the result of that evaluation.

The name suggested for it was UPDATE:

>> x: <some-tag>
>> x: update if false [<unused-tag>]
>> print x
<some-tag>

 >> x: <some-tag>
 >> x: update if true [10 + 20]
 >> print x
 30

This seems very useful to me. While simple conditionals can move assignments into the block of code, e.g. x: if c [v] => if c [x: v], more complex instances might have several points they'd have to selectively do the same assignment:

number-of-variants: update case [
    whatever1 [do some stuff, 1020]  ; update for this case
    whatever2 [do some stuff, void]  ; don't update in this case
    whatever3 [do some stuff, 304]  ; update for this case 
]  ; don't update if no matches

But what we noticed was that UPDATE has been taken for a somewhat esoteric port action that I don't think anyone is using at the moment.

REBOL: Update - Function Summary

I'm not totally getting it, as it seems sort of like a WAIT statement, a SYNC, a FLUSH, a FETCH... I dunno. UPDATE seems a strange word to grab when there's this nice other function for it.

It's in use... but the only mentions are internal. It's what native port actors use to "respond to WAKE-UP". The name could be bumped to ON-WAKE-UP.

I'm suggesting something for the anti-default though

>> help something
something is a WORD! bound to a context, but has no value.

for the reason that something can not come out of nothing

Alternatives include becomes and be which aren't used.

UPDATE also is used for database manipulation.
TLUAFED as anti DEFAULT.
Or some other creative option, INGEST, TAKE-IN, TRY-ASSIGN
I like WHATEVER too.

@gchiu suggests MIGHT

I think I like it. Though one thought is that x: might (...) has the problem of it sounding a bit like the thing that might happen or not is the code in the block running, vs the assignment that might happen.

(Writing might x: (...) may make it look a bit more like it's the assignment which might happen, at the cost of making it look like it might assign the block literally. :-/)

Anyway, MIGHT is my favorite so far.

Use your magic wand
x: DIBBEDEEDABBEDEEBOO [...]

Yes MIGHT is a good candidate.
Introduce it and if a better option comes along it can always be replaced by that.

Well, instead of might we could use could.

I found a 2020 thread where I just repeated this idea...again. In that post I called it PERHAPS. Which I like a bit better as a part of speech than MIGHT.

Eeeeh. No. Seeing the x: (...) looks too much like the assignment is a done deal before MIGHT (or whatever) has a chance to say anything about it.

I should point out that now things like CASE and SWITCH return NULL again, so PERHAPS would either have to consider both VOID and NULL as non-updating states... or you'd have to put MAYBE on nulls.

x: perhaps case [...]

I Want This Function, So PERHAPS It's Time To Just Add It

We've been talking about it for SIX YEARS.

1 Like