The first phase of my recent set of changes was to introduce the internal concept of type families. These are groups of type ID tags that represent different categories of semantics. For example, I used to reserve everything above the ID number 20 as "structure" types; now, structure type IDs start at 0 and are simply tagged with the "Structure family" bitmask. This mask is the upper 8 bits of the 32-bit type ID tag, meaning that there can be as many as 256 different type families and 16.78 million (give or take) types in each family. Not too shabby, I think.
The practical upshot of this is more interesting. As an experiment, earlier tonight I added weak type aliases ("typedefs" in C/C++ parlance) to the language. That's just a mapping of a string to a type ID to the compiler; if you want to call "integer" something else, like "bletcherous_number", you can do so. Integers and bletcherous numbers remain fully compatible and interchangeable.
Much more powerful, though (and correspondingly harder to implement) is the second feature I finished this evening: strong type aliases. Strong type aliases give you the ability to hijack an existing type's representation without allowing other things with the same representation to be considered of the same type.
Here's a concrete example: suppose I have a program in which both Meters and Inches are handled, and represented by the "real" built-in type. I don't want to allow a number that "means" meters to be assigned to a number that "means" inches, and so on; so I write an Epoch program like this:
type Meters : real
type Inches : real
entrypoint :
{
Meters m = 3.14
Inches i = 2.78
m = i + 2.0 // Uh oh! Compile error!
}This sort of functionality also comes in handy when interoperating with things like the Win32 API; instead of just having a lot of things that are "integer" passed around to handle HWNDs, HANDLEs, and whatever else, I can create a strong type alias for each semantic type that the API deals with, and ensure that I never accidentally try to render text using a socket instead of a font.
Of course, dealing with units like meters and inches is only so useful if you can't convert between them; I intend to add a full dimensional analysis system at some point, which will let you do things like this:
dimension Meters : real
dimension Inches : real
conversion Meters m -> Inches i = m * 100 * 2.54
entrypoint :
{
Meters m = 9.81
Inches i = convert(Inches, m)
print(cast(string, i))
}
And of course also:
dimension Meters : real
dimension AreaMSq = Meters * Meters
entrypoint :
{
Meters width = 3.0
Meters height = 10.0
AreaMSq area = width * height
}Dimensional analysis is a nice thing, but even better than that are algebraic sum types, which are also on the list of things I want to add to the language soonish. After sum types, I can do generic programming, and that will enable all manner of kick-ass stuff like the scribblings I left in my last entry.
All in all, exciting times for Epoch! Stay tuned for more...
