Monthly Archives: May 2014

Operator overloading — development driven by demand

I would like to write the development is driven by design, but it does not happen — unfortunately I don’t have enough time to properly take care of Skila, so I already marked several things to fully resolve in undefined future, and I hope they can be resolved.

I started to port my small utility written in Ruby and right of the bat — I have plus operator on strings and iterator over strings. I didn’t intend to implement those for my minimal set, but I like comfort when programming, and both of those features add comfort to a language.

Besides, iterator reminded me the importance of type system (again). You would like to iterate over an array, no problem in C#, because array is a reference type, but in Skila (which for now has type system similar to C++) an array can be placed on stack. And iterator needs a reference/pointer to container — since you can store iterator it might be the case the array will be removed from stack, while iterator will be still in use. What now? Undefined behaviour? Crash? Added countermeasure (I think of weak pointer)?

So on one hand, such approach to implementing the language and compiler leads to mess, on the other it helps face all the problems fast, so you won’t spend a lot of time pursuing impossible.

So far, it is possible, so operator overloading is done (just a fancy name of the method), iterators are ahead of me.

Advertisement
Tagged , ,

Static inheritance of an interface

The more I dive into implementing Skila the more I appreciate the role of the type system. Yet another interesting case is with generics — how to make them compile-once and be efficient for both complex and native types? Say, you would like to implement “Vector<T>” — one operation which has to be executed is copying the value.

In C++ world you define template and when using it, given type appears viable (or not), however it goes with the price of compilation of each instantiation of the template. In C# you can specify constraint that “T” has to inherit from something like “ICopyable”. But native types do not inherit from anything, so how to make them fit into a template?

I noticed that generics supports object oriented programming, but is not dependent of it. So sure, you can express such constraint, but you can specify another one — making “T” to provide all methods (or extension functions) declared in “ICopyable”.

This makes type such as “Int” fit for “Vector”:

class Vector<T>
  where T : static ICopyable;
...

Note the keyword “static”, “T” is no longer checked against given inheritance, but against providing a set of methods.

The methods are checked when “Vector” is instantiated, if you would like to make the code more explicit specify static inheritance when defining the class:

class Foo : static ICopyable
...

This does not add regular inheritance, instead it enforces the given suite of the methods when defining the class “Foo”, not when calling for “Vector<Foo>”.

Tagged , , ,