What to call the anti-DEFAULT?

Development Naming
1

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.

2

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.

3

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.

4

@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.

5

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.

7

Well, instead of might we could use could.

8

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
9

Make that seven. :roll_eyes:

But I had the thought--and this is an important thought to have now vs. later...

RETAKE MAYBE, MAYBE => OPT(IONAL)

Today's MAYBE turns nulls into voids, with a shorthand of ?:

>> append [a b c] maybe pick [c d] 3
== [a b c]

>> append [a b c] ? pick [c d] 3
== [a b c]

This could alternatively be OPTIONAL or OPT or ?

>> append [a b c] optional pick [c d] 3
== [a b c]

>> append [a b c] opt pick [c d] 3
== [a b c]

>> append [a b c] ? pick [c d] 3
== [a b c]

Then we could imagine MAYBE being this updater thing, where it seems pretty literate:

>> x: <foo>

>> x: maybe switch 1 + 2 [0 ["a"] 3 ["b"]]
== "b"

>> x: maybe switch 3 + 4 [0 ["c"] 3 ["d"]]
== "b"

But today's OPTIONAL in PARSE does not produce VOID, it actually produces NULL. Most of the time it doesn't matter because you're not taking the assignment.

But would there be uses of an OPT parse giving you void?

>> append [a b c] parse [d e] [opt across some word!]
== [a b c [d e]]

>> append [a b c] parse [1 2] [opt across some word!]
== [a b c]

You don't get a parallel to this today by saying opt parse [...] because that will void any reason that the parse didn't succeed. You may have erroring cases that you want to error as a non-match, and some branches in your rules that want to give void. It's strictly more powerful--and now that I look at it, likely very useful.

There was an abandoned attempt to use TRY in PARSE instead of OPT, that I decided I didn't like because [try "s"] seemed weirder than the more declarative [opt "s"]. But here we could have both options... one that gave you VOID and the other that gives you NULL.

Then MAYBE would be free for this cool updater construct that I really want...

Not only do I think this doesn't look bad, but I like the availability of the OPT shorthand vs. written out MAYBE if you want it. And PARSE could define ? as a synonym for OPTIONAL as well.

:thinking:

2 Likes