Software Development

While developing my type system, I discovered something that was there all along, but isn't really discussed much. I'm talking about implicit types. Or rather if there is such as thing as a non-type. In my type system, everything is a type. This leads to the obvious confusion about how to differentiate between a value and what we commonly describe as a type.

I wanted a consistent type system, so I decided to have values as subtypes to their common types. So 4 is a subtype of Integer. But that's not the whole story. This description is wholly inadequate for our purposes. Four isn't exactly an Integer. The Integer type is the set of all numbers (without fractions). Four is only one of these values. So that's the main difference between a value and a type. A type is the enumeration of all possible values. This is commonly known as a set. A value is ONE value from this set. So when we declare an instance, it's assumed that we are declaring memory for this ONE value. The value only exists at runtime.

But in my system, everything is a type. So I needed a way to define values at design time. The IDE and compiler will use these values (because these values are in turn needed to define type properties). I simply decided that if a type has the Enum type as a base type, then you've declared a value. The primary base type defines the set from which the instance may take its value from.

Simple enough I think. What I really like is the unintended consequences of this decision. Say you define a class as you would normally do where you list a number of instances including instances of other compound types. Here's an example in pseudocode (the initializers are default values).

class Complex
{
  double r(0.0);
  double i(0.0);
};

class Test : public Enum
{
public:
  int a(2);
  int b(4);
  Complex c(r=1.0,i=0.0);
};

Test value(b);  // Can only contain ONE item from the Test class (a,b or c).

You can use this definition of Test as a set. Because that's what it is. It contains a list of items. What you can now do is subtype it along with the Enum base type and you can define your very own value that can be chosen from one of the items in your class. Each item would also have its own type. As such, you have a way to inspect the internals of any class directly from within the type system without any special functionality like reflection. It's a basic feature.

A difference is that there is no such thing as instancing anymore. Everything that is defined exists. At compile time, the compiler strips out any and all unnecessary information. There's more to this, but that's for another day.

As far as the GUI is concerned, I'm done the core functionality of it and it works great with Direct3D. There is one function I don't like that I had to include. You cannot nest render target operations, so I have to do two tree traversals instead of just one when drawing on screen. One for any component that caches its graphics and then another one for drawing on screen. It seems to work much better than I thought, so I'm happy with it. I'll be creating some more graphical components and then I should finally have something to show. I want to stress that I'm only working toward being able to connect components together and getting something running on a single core. Once that's done, I'll start adding stuff in that people want so that developers can produce their own stuff for Project V.