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? - #3
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 RAISED? is unstable, based on the presence or absence of that issue:
group "list that evaluates expressions as an isolated group"
~splice~ "fragment of multiple values without a surrounding block"
(node1)
[any-series? any-plain-value? any-sequencable?]
error "error context with id, arguments, and stack origin"
~raised~ "trappable error cooperatively returned from a function call"
#unstable (node1 node2)
[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 the nodes 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 "error context with id, arguments, and stack origin"
'~raised~ "trappable error cooperatively returned from a function call"
(node1 node2)
[any-inert?]
Uh, well. Technically that works. There's a lot of things that could technically work. You could say {~raised~} or make it look like a meta-tripwire:
error "error context with id, arguments, and stack origin"
~<raised>~ "trappable error cooperatively returned from a function call"
(node1 node2)
[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 "error context with id, arguments, and stack origin"
~raised~:U "trappable error cooperatively returned from a function call"
(node1 node2)
[any-inert?]
You can't miss it... staring you in the face. It could also be a PATH! or a TUPLE!
error "error context with id, arguments, and stack origin"
~raised~/U "trappable error cooperatively returned from a function call"
(node1 node2)
[any-inert?]
error "error context with id, arguments, and stack origin"
~raised~.U "trappable error cooperatively returned from a function call"
(node1 node2)
[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 ~raised~:*, 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...)