I was facing a little bit of a design question with the %types.r table, that I talk about here:
Which Antiforms Are In Use? - #4
I'd come up with the idea that using a quasiform in the table was a good semiotic way of suggesting the name of the antiform state of a type. I was happy with that, but then the question was how was I to distinguish a stable antiform from an unstable one.
Originally it was done with the presence of a #unstable ISSUE! in a sort of random spot. Here you can see SPLICE! is a stable antiform, while ERROR! is unstable, based on the presence or absence of that issue:
block! "list of elements that blocks evaluation unless EVAL is used"
~splice!~ "fragment of multiple values without a surrounding container"
(payload1)
[any-series? any-branch? any-sequencable?]
error! "context with id, arguments, and stack origin"
~failure!~ "error state that is escalated to a panic if not triaged"
#unstable (payload1 payload2)
[any-inert?]
This didn't sit well with me, and I think what I didn't like is that it didn't connect #unstable to the antiform state. If I were looking at this, I'd wonder "are payload1 and payload2 unstable?" Because that's the line it's on.
Ren-C has a wide breadth of parts you can use (although this is part of bootstrap, so it doesn't have all the parts of the modern executable). And you can pick random ideas. What if it were quoted, and that meant unstable?
error! "context with id, arguments, and stack origin"
'~failure!~ "error state that is escalated to a panic if not triaged"
(payload1 payload2)
[any-inert?]
Uh, well. Technically that works. There's a lot of things that could technically work. You could say {~error!~} or make it look like a quasi-tag:
error! "context with id, arguments, and stack origin"
~<failure!>~ "error state that is escalated to a panic if not triaged"
(payload1 payload2)
[any-inert?]
That looks nice, but maybe it looks too nice. It's so smooth as to be unnoticeable if you're scrolling through.
Which is why I ended up choosing something purposefully jarring:
error! "context with id, arguments, and stack origin"
~failure!~:U "failure state that is escalated to a panic if not triaged"
(payload1 payload2)
[any-inert?]
You can't miss it... staring you in the face. It could also be a PATH! or a TUPLE!
error! "context with id, arguments, and stack origin"
~failure!~/U "failure state that is escalated to a panic if not triaged"
(payload1 payload2)
[any-inert?]
error! "context with id, arguments, and stack origin"
~failure!~.U "failure state that is escalated to a panic if not triaged"
(payload1 payload2)
[any-inert?]
But I think I like the CHAIN! for some reason. It's jarring enough to see it, but the colon is a very "balanced" character. And you can see clearly that the (U)nstable is "correlated with" or "modifies" the antiform state, which addresses the problem I had with #unstable.
It might look better as ~failure!~:*, and it might not. But I think this is sort of an interesting case study, because it's all playing into that subtlety of how to make something that looks passable yet still triggers that primordial "ick" enough to get you to ask questions. Then once you familiarize yourself you know what it means, and when the ick goes away you see it as a smart design.
It's interesting to me that I feel like I like the CHAIN! version as :U noticeably more than /U or .U, which is a further validation of having that part in the box.
Also interesting to note here is the reasoning why there are no antiform CHAIN! or PATH! or TUPLE!, because cases like this show it's more valuable to be able to have quasiforms as elements than to have a quasiform path state.
(Otherwise, ambiguity... what is ~:foo:~ ? Is it a quasiform of :foo:, or is it a 3-element CHAIN! with quasiform blank in the first and last slots? I think quasiform :foo: is sufficiently useless to favor the definition that gives us things like ~/home/whatever as a legal path...)