This historical thread covers the decision to migrate of "DATATYPE!" toward becoming a TYPE-BLOCK!, e.g. an actual structural form in the language.
Ultimately the representation chosen was to use
>> type of 1020 == &[integer]
The discussion is kept for reference, but see notes about the migration of DATATYPE! to this new idea.
Datatypes have problems. One is that there's no clear representation for them literally, so they tend to just look like WORD!s:
rebol2>> word? first [integer!] == true rebol2>> type? 10 == integer! rebol2>> word? type? 10 == false
As a band-aid over this conflation with words, Ren-C has been using construction syntax in the console...but it's quite ugly:
>> type of 10 == #[datatype! integer!]
We also face the question of extensibility of types... and it's hard to think of a better extensibility mechanism to use than the existing symbol engine that is behind ANY-WORD!.
But making them plain WORD! is not very desirable. We are used to writing things like
make object! [...]. And we don't want MAKE to have to quote its argument. Hence, OBJECT! would have to evaluate to something.
We could say
(object!: 'object!) but that seems like it would get into some ugly situations.
What about the new @WORDs?
@integer could act as a datatype, as well as an ANY-WORD!.
It has the advantage of being inert in the evaluator:
if @integer = type of 1 [print "Sanity prevails..."]
Redbol compatibility could still work:
So the main question would be, how often is it that you have a slot that might want an @word -or- a datatype? How frequent is that need for polymorphism?
When I look at the landscape of problems, it seems to me that an evaluator-inert type that has an intrinsic extensibility like this would be pretty much ideal for denoting a datatype. No construction syntax, just good ol' reliable behavior.