COMPOSE has a great feature of being able to add quotes to the slot, by grafting the quotes that are on the slot onto the synthesized result. It adds onto existing quotes:
>> compose [field1: '(first [a]) field2: '(first [''b])]
== [field1: 'a field2: '''b]
You can also compose quasi-states, but only on things where it would be legal:
>> compose [field1: ~(first [a])~] ; Note: making ~''b~ would be illegal
== [field1: ~a~]
But as it happens, what you want a LOT of the time is to create either quoted states from non-antiforms, or quasi states from antiforms.
If quoted slots were willing to do that, it would look like:
>> compose [field1: '(first [a]) field2: '(null)]
== [field1: 'a field2: ~null~]
I've struggled with the question of whether or not to be willing to do this, instead of erroring.
If it were to be done, it would certainly have to only do it to antiforms after they decayed. We don't want it to be composing in quasi-errors instead of reporting them. PACK!s shouldn't be composing as packs, but as the decayed values.
But how bad is it if we are willing to quasify stable, decayed, antiforms?
I KNOW this would be very useful.
We'd still be getting errors on trying to compose in NULLs to slots on regular compose, and it's only when you used this feature that it would be suppressed.
Having it be a refinement, like compose:relax... e.g. relax in the sense that you don't error on nulls when you don't absolutely have to, feels awkward.
I Think I Like Reverse-Biasing The Safety
I guess the way I'd put it is: if you think the safety is important, don't put the quotes on the outside of the group. Put it inside:
>> compose [field1: (quote first [a]) field2: (quote expression-maybe-null)]
** Error: that expression turned out to be null
Quotes on the outside then becomes a power-user feature, and it does what a power user wants:
>> compose [field1: '(first [a]) field2: '(expression-maybe-null)]
== [field1: 'a field2: ~null~]
Yup. I think I like that. Put your quoting inside if you want the null protection, makes sense.
What About Composing VOID In Quoted Slots?
VOID is a PACK!, but it's an undecayable one, so it has special handling nearly everywhere.
Actually this clears up a loose end:
>> compose [''(void)]
== ['~[]~]
Today you get a sort of outlier error there, telling you that void can't vaporize, because [''] isn't legal. I like the idea that there's a behavior/answer.