Tag Archives: iterators

Associated reference

I’ve just made up the term “associated reference”. While many features in Skila are simply borrowed from other languages I have never encountered this one before. And it looks bad — it is complex, fragile and I would gladly get rid of it, but I can’t, and here is why…

Consider such case as passing few arguments to C# variadic function. Variadic parameters in C# are arrays, arrays are allocated on heap, and this is inefficient. Skila has limited support for C++ like references, so in Skila we create array on stack and pass a reference to it to the function. It is efficient. Step one sounds good?

Step two — we are inside the function and we would like to iterate over the variadic parameter. We need an iterator for it, and in turn iterator needs a collection to iterate over. Passing the collection as a value would mean copying collection, passing it as a pointer is desirable, but in a case like the current one we don’t have a pointer, just a reference. So the reference is the only option. The logic looks sound.

Step three — we need to store that reference inside iterator instance. And this makes the iterator a special kind of type — an associated reference.

Once introduced, all hell with validation breaks loose. For example associated reference type can have only single field with reference, it can have only one constructor with single parameter, which is of reference type. The associated reference type can be passed only by reference and its lifetime has to be limited to the life of the “seed” instance.

Fragile, complex, first feature which does not seem right.

And yet the only alternative I see is redesigning the concept of a stack by allowing to partially unwind it (to preserve referenced instances). At first glance it looks even worse than associated reference so I stick with it for a while.

Tagged , , ,

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.

Tagged , ,