Variadic functions — it’s clean up time

OK, I did it. The last feature I wanted to have in my intro toolbox — variadic functions. This time I borrowed the design from Scala, not from C# because I like it better — especially in cases when you use template function and it is unclear whether your array will be passed as one argument or expanded to multiple arguments:

var arr = new Array<Int>(5);
foo(arr);
foo(arr:~);

Assuming “foo” is variadic function taking “Ints” the first call is incorrect, only the second works because it unfolds entire array and passes the values one by one (technically it unfolds nothing, it is just semantic notion).

However even Scala is not complete — too often I need to write variadic function with at least 2 parameters. Since I didn’t see everything Skila has flexible limits:

func foo(params[2..20] p Int) ...
func foo(params[2..] p Int) ...
func foo(params[..20] p Int) ...
// not too much sense, if you ask me
func foo(params[2] p Int) ... 

I could say this is the time I rest a bit, rethink syntax, try to write some programs for real, and finally upload the first version of Skila (no matter how embarrassing the code looks like — it is a mess, seriously).

But as it appeared with recent issue of Dr.Dobb’s I also have to read more about programming language Nimrod. At first glance it seems it is well designed, with similar concepts in mind as Skila — I would not like to duplicate the efforts so I have to make sure it is not the last stop for Skila.

Advertisement

17 March, 2014 — Compilers course again

Without any doubt I highly recommend enrolling on Compilers course by Prof. Alex Aiken. Since I had some time to make preparations I decided to include skeleton project for NLT generator, and the way COOL assignments are organized made me refine some features of NLT.

Among others there is one which existence derives from limitation of C# — you cannot define enum which inherits from the other enum despite the fact the enum in C# is strong alias of int (and you can inherit classes containing ints as you like). In other words if you have to define constant integer values gradually you have to use old boring ints (and lose value safety).

I am far from reaching enums in Skila but I won’t make the same mistake. Anyway, both frameworks — COOL C# and NLT — are uploaded and waiting for you!

Code injects — collections are getting closer

I see a scary pattern lately. I add new feature to Skila pretty quickly, but when it comes to cleaning the code (sadly, it is messy) I can spend a day on refactoring, polishing, removing dead pieces, and at the end it appears that I cleaned away one thing too many and I have no clue how to fix it while moving forward — so instead I have to rewind the changes, I make half of them again with commit on each step, and then I am too tired to make the second half, so I call it a day (the second one). The weekend just passes and I don’t know when…

I am working on at least one collection to introduce variadic functions in Skila, and this is the time when Skila and target language have to meet in the same code:

class Array<T>
	<?php
	public $data;
	?>

	func construct(size Int) do
		@ = size;
		<?php
		$this->data = array();
		?>
	end  
end

So far I didn’t solved the name matching problem, I rely on common sense of Skila translator, but I am too eager to finally see Skila programs working.

What’s cooking — type generics and method’s zoo

I’ve just finished generics with type parameters, no surprise since I already implemented symbol generics. So far Skila does not have constraints, but I prefer to cover more ground in order to have working language in hand. Collections (and passing them around) is my next step.

Since this will take some time, I might make a break and add static virtual methods. You can say — “what? How a static method can be virtual”. Well, in C++/C# it cannot, because it was implemented that way. All it takes is one look from different perspective — take a regular virtual method and limit its access to static features only. Here you have it — static virtual method.

It is not a feature I will die for, but I too often bump into a problem which could be nicely solved having static virtual method and its cousin — pinned method (new concept), static or not. Pinned method is just like virtual one but it is erased with each new class in hierarchy, meaning once you add it somewhere you have to redefine it in each descendant class. This is pretty similar to pinned constructors (which are already implemented in Skila).

With such arsenal you can finally decide what is better for you, static factories or per instance, you can handle some traits of the class (type) with static methods. Nothing revolutionary, just more freedom and flexibility.

And since there is already so much variety why not add yet another one, with even more limited access — actually with no access at all. Function/method which relies only on its parameters with no side effects, pure function. We’ll see…