This last summer I spent a considerable amount of time refactoring i-lang. Since I started implementing this programming language in early 2012, it had accumulated quite a bit of cruft, and it was difficult to continue moving forward.
Refactoring type system
One of the first internal improvements that was made was to overhaul the internal type system. Before, the type system was simply passing around a boost::any. However, this became trouble some as all parts of the code would have to know about each type so that it could cast it locally. In many places the code began to look like:
if(a->type() == typeid(Object*)) {
a = boost::any_cast<Object*>(a);
// ...
} else if(a->type() == typeid(Array*)) {
// ...
}
It became even worse when there were two different types involved, as can be seen in the case of performing arithmetic.
Now, the type system has been rewritten to better make use of C++ template and virtual function systems. This means that one can write code like:
ValuePass a = valueMaker(1);
ValuePass b = valueMaker(2.4);
ValuePass c = a + b;
assert(c->cast<float>() == 3.4);
assert(c->cast<int>() == 3);
assert(c->cast<bool>() == true);
assert(c->cast<std::string>() == “3.4”);
The real beauty of this type system can be seen when using the foreign function interface, where the value of arguments can be “injected” into local variables. This means that a function can be written as:
ValuePass func(Arguments &args) {
int a;
double b;
std::string c;
ilang::Function d;
args.inject(a, b, c, d);
// The arguments are casted to the type of the local variable
// in the case that a cast fails, an exception will be raised
// which is the logical equivalent to calling a function with
// the wrong type signature
// ... (body of function)
return valueMaker("hello world");
}
Changes in the type system at the language level
Before this refactor, types in i-lang were defined in a global table of identifiers called variable modifiers. A variable could have more than one modifier attached to it, and each modifier is used to check the value being set to a variable. What this roughly translates to would be something like:
define_type("Unsigned", {|a|
// check if the value being set, which is passed as argument a, is greater or equal to 0
return a >= 0;
});
// use this type like
Unsigned Int b = 5; // both Int and Unsigned are called to validate the value of '5' is the correct type.
Looking at this implementation of a type system, it does not seem that bad when compared to other programming languages. As displayed here it is missing the concept of a namespace or import scope, but otherwise it is fundamentally a type system where types are given names and then later used to reference that type. However, this concept of a type having a name fundamentally goes against i-lang’s concept of names only being used as place holders for values, vs having an explicit places in the language. (eg: class required_name_of_class {} vs name_bound_for_use_later = class {}). This lead me to question what does a type system fundamentally do. In lower level languages such as C/C++ a type system provides information about the space required for an object, however in a higher level language such as python (which i-lang is more similar to on this point) values are just fixed sizes and then pointers to larger dynamically sized objects when required. Type system also provided casting between primitive types, such as a 4 byte integer casted to a floating point. This on its own isn’t that interesting as there are limited number of primitive types and similar operations can be accomplished with code like `1 * 1.0` or `Math.floor(1.2)` for casting. Finally, type systems provide a way to identify the type of some value, which can be further used by a language to provided features such as pattern matching when calling a function. Now, choosing to focus on this last issue of a type system lead to i-lang concept of a type system, which is that a type is simply a function which can identify if a value is a member of a given type.
The idea of using just a function to identify a type can sound a little strange at first, however, after playing with it some, the idea itself can be seen to be quite powerful. Here is a quick example of using this type system to implement pattern matching on the value passed to a function.
// This is a function which returns a function that compares the value
// the returned function gets with the value the first function was called with.
GreaterThan = {|a|
return {|b|
return b > a;
};
};
LessThan = {|a|
return {|b|
return b < a;
};
};
EqualTo = {|a|
return {|b|
return b == a;
};
};
Example_function = {|GreaterThan(5) a|
return "The value you called with is greater than 5";
} + {|LessThan(5) a|
return "Then value you called with is less than 5";
} + {|EqualTo(5) a|
return "The value you called with is equal to 5";
} + {
return "The value you called with didn't compare well with 5, must not have been a number";
};
Int GreaterThan(0) LessThan(10) int_between_zero_and_ten = 5;
In the Example_function, we are combining 4 different functions, each with different type signatures. Additionally, we are creating types on the fly by calling the GreaterThan/LessThan/EqualTo functions which are using annoymious functions and closures. This method also allows for classes to have a place in the type system. We can now easily create special member of a class to check if a value passed is an instance or interface of the class type.
sortable = class {
Function compare = {};
};
// check that the array members all implement a compare function and are an instance of a class
sort = {|Array(sortable.interface) items|
// ...
};
Refactoring Objects and Class to appear like functions
Before, i-lang use syntax similar to Python or JavaScript dicts/objects when constructing a class or object. This meant that these items looked like:
class {
Function_to_check_type type_name: value_of_type,
Another_type another_name: another_value,
no_type_on_this: value
}
However, in ilang, except when prefixed with `object` or `class` the use of `{}` means that it is a function. (eg: a = { Print("hello world"); };) Additionally, colons are not used anywhere else in the language, which made me question why was this case such a special one. This lead me to ask why not use equal signs and semicolons like everywhere else, meaning that defining a class would appear as:
class {
Function_to_check_type type_name = value_of_type;
Another_type another_name = another_value;
no_type_on_this = value;
}
Furthermore, is there any reason to exclude loops and if statements when constructing a class? Allowing control flow when the class definition is constructed makes this act identical to a function.
a = true;
class {
if(a) {
b = 5;
} else {
b = 6;
}
}
Final thoughts
By starting by cleaning up the internals of i-lang, it allowed me to take another look at the language and determine why certain choices were made at first. Bootstrapping a new programming language takes a considerable amount of effort, and could easily lead someone to defining something like print a function (as python recently changed away from in version 3). In my case, I was creating special mechanisms for constructing class/objects and defining types for variables largely because the type system, scopes, and function internal interfaces were all poorly designed in the first iteration of the language. Now that the internals have been cleaned up, it makes it easier to see that these changes are wins for the language. Now, I doubt that I would have been able to come up with these changes right off the bat with the first implementation, as it was only through the pain of the first implementation for which the need for these changes became apparent.