Is Signaling With Tripwires Good Or Bad?
I don't totally remember the motivation, but I came up with a feature of ASSERT where you could give it a handler...to receive the assertion condition that failed, and process it in some way:
>> h: func [cond] [print ["condition is:" @cond]]
>> assert:handler [1 = 1, 2 = 3, 3 = 4] get $h
condition is [2 = 3]
** Error: Assertion Failure....
Maybe it's interesting. I dunno. But something I had in it was that ASSERT would check the return value from the function, and if it was an ~ignore~ WORD! antiform it would not raise an error, but would continue processing the conditions.
We don't allow arbitrary keywords any longer, but the feature could still be approximated with a tripwire as ~<ignore>~.
>> h: func [cond] [print ["condition is:" @cond] return ~<ignore>~]
>> assert:handler [1 = 1, 2 = 3, 3 = 4] get $h
condition is [2 = 3]
condition is [3 = 4]
>>
There have been some changes to where functions return nothing by default, if you don't have a return statement. But this doesn't apply to lambdas.
So some of the idea here is to let you use a thing like a lambda and have a weird/ornery out-of-band kind of result that signals a behavior, while other values (blocks, integers, anything you might randomly synthesize) won't. e.g. h: cond -> [append log cond] as a handler would log the assert but still fail, while h: cond -> [append log cond, ~<ignore>~] would log and not fail.
Obviously there's potential for failure or conflation if you call a function that just so happens to evaluate to ~<ignore>~ and you didn't mean to ignore. But eh. It is what it is, and it's kind of cool.
Making this kind of thing somewhat tractable is the fact that tripwires allow comparisons (while nothings don't). So they are more readily used in this way, despite being "ornery".
I'll keep this around for now.