Since datatypes are now antiforms, you can't MOLD them.
MOLD is reserved for things that can be array elements. And the exceptions are put to good use. For instance molding a splice gives you the list without delimiters:
>> mold [a b c]
== "[a b c]"
>> mold spread [a b c]
== "a b c"
And molding a void gives you null back:
>> mold fourth of [a b c]
** Error: Can't mold ~null~ antiform
>> mold maybe fourth of [a b c]
== ~null~ ; anti
I would not be a fan of arbitrarily giving people an answer that they might want just because they're used to using mold for it:
>> type of 1020
== ~{integer!}~ ; anti
>> mold type of 1020
== "integer!" ; no!
So we're stuck with a different way of saying this, which is a bit verbose:
>> to word! type of 10
== integer!
It's not that laborious but it seems it could have an abbreviated form. My first thought was just to do as history does, paralleling TYPE?/WORD
>> type-of:word 10
== integer!
>> type:word of 10
== integer!
But I wondered if that might be "unchained" to get rid of the colon somehow:
>> typeword of 10 ; hrrrm, no.
== integer!
>> typename of 10
== integer!
I don't think TYPENAME looks bad, but it sounds like something you'd apply to a datatype... not a value whose type you are requesting, I'd be less surprised if it acted like:
>> typename of integer!
== "integer!"
MOLD TYPE OF => TO WORD! TYPE OF for now...
I'd like something shorter, but that's something I think is pretty much guaranteed to be working from here on out.
I'm using TO WORD! instead of TO TEXT! because it's cheaper (doesn't have to make a copy) and many of the contexts I'm in are merging strings.
(To point out that it's cheaper, I could use AS WORD!, though that exposes an implementation detail that the type is available as a pre-existing word.)