On Fri, 2016-04-01 at 12:02 +0900, Cohen Malcolm wrote:
> Or we could actually go back and do
> typealias properly (some people might agree with you that "type alias" is a
> bad idea, but a very large number of people would strongly disagree).
When we were debating typealias versus a new type, I had concluded that
there was nothing that could be done with typealias that could not be
done with a new type, but the opposite is not true. For example,
typealias is useless for generic resolution, or even more simply, just
for getting the processor to check that intrinsic assignment is OK (or,
more importantly, not OK). Aleks Donev was in the "strongly disagree"
camp, but he eventually came to with me.
There was a remark some time ago (I don't remember from whom) that one
could fake an enumeration type by defining a new derived type with one
integer component, the value of which is the representation of each
enumerator of the type. Then a bunch of named constants provide the
enumerators. One could maybe provide a type-bound INT, and a
constructor that verifies that the value is within range. It seems that
could be done by a tree transformation during or shortly after parsing,
with the rest of the processor completely unaware of what happened up
front. Thereby, there would be essentially no impact on the type system
from the processor's point of view. Maybe the standard would be a bit
more difficult to get right.
|