So I was noticing you couldn't do this anymore...
func compose:deep [x [word! (integer!)]] [ ... ]
Because integer! is an antiform of ~{integer!}~, and you can't put antiforms in blocks...
But let's say you LIFT it (or use the "power user" lifting-quote in compose):
>> compose:deep [x [word! (lift integer!)]]
== [x [word! ~{integer!}~]]
>> compose:deep [x [word! '(integer!)]]
== [x [word! ~{integer!}~]]
We have sort of free reign to decide what quasiforms do in type spec blocks. For instance, quasi-blocks match packs with those types, e.g. ~[integer! block!]~ would match a pack antiform like ~['1 '[a b c]]~. So it's not like the quasiform states are uniformly treated literally.
So why not have quasi-fences mean typecheck that as a datatype?
Seems like a winner to me (and reminiscent of my recent realization of "Quasiforms can mean whatever we want to design them to do in PARSE")
TYPE OF including Quoted/Quasi Status?
In the dawn of generalized quoting, I thought about putting quote marks on the datatype to reflect how much quoting there was:
>> type of first ['''a]
== '''[#datatype word!]
But I realized having quotes on the outside of the type had bad properties... it was no longer a datatype, it was a QUOTED!. And if you put it somewhere and it evaluated those quotes were easy to lose track of.
So as using a list type came up, I thought putting the quotes inside the list made more sense.
>> type of first ['''a]
== &['''word!]
But with the dawn of antiforms and quasiforms, there was a problem. If you wanted to signal an antiform you'd perhaps do that with a quasiform.
>> spread [a b c]
== ~(a b c)~ ; anti
>> type of spread [a b c]
== &[~group!~]
But then your answer for quasiforms would have to be quoted...and your answer for everything else would be one level quoted higher than you wanted it:
>> type of first [~a~]
== &['~word!~] ; :-(
>> type of first ['''a]
== &[''''word!] ; four quotes?! :-(
That was hideous. But as of now, antiforms are getting their own types:
>> type of spread [a b c]
== ~{splice!}~ ; antiform
Which means maybe the old system could be used more sensibly:
>> type of first [~a~]
== ~{~word!~}~ ; antiform
>> type of first ['''a]
== ~{'''word!}~ ; antiform
That doesn't look hideous. In any case, I proposed the idea that you could produce these datatypes from other ones, e.g.
>> integer!
== ~{integer!}~ ; antiform
>> quoted integer! ; antiform
== ~{'integer!}~
>> quoted-datatype? ~{'integer!}~ ; antiform
== ~okay~ ; anti
What motivated me to think about TYPE OF giving these distinct answers e.g. for quasiforms and quoteds is that I want PARSE to be able to dispatch on quasiforms now, and it doesn't have a good way to do that unless it distinguishes them.
Again--this is an old idea reviewed in light of new developments. It doesn't look completely nuts. I'm in the throes of the antiform datatype conversion, so I'll probably have more to say shortly.
UPDATE: The antiform datatype code boots after less than 2 days work! But... booting is the beginning of a lot of details and additional design work.