Memory chunks and inheriting enums

Type Chunk type represents a chunk of memory — either on stack or on heap. The latter use is pretty obvious, such types as Array or String will use it. The placement on stack is crucial for making variadic functions efficient — take for example C#, it supports variadic functions, but since arrays are allocated on heap, the comfort of using variadic functions comes at such price that it is not uncommon to see several overloads with unrolled parameters just to avoid variadic parameters.

Having Chunk allows efficient implementation of variadic functions — there is no memory allocation, just extra internal “parameter” (number of elements).

Unrelated to memory, another new feature is ability to inherit enums. From time to time I was annoyed I had to repeat enums in C# just to add few new entries (and remember to keep the same common values), so in Skila you simply derive one enum type from another and share common values. I am not sure if the inheritance is the correct mechanism here, because substitution rules are reversed for enums (you can pass base value when the derived type is required), but since it works I leave it as it is.

Ahead of me is reimplementing old rules of method-property derivation.

Advertisement

What is easy — generics with nullable types not for sure

For a week I have been removing features from Skila (so far just two) and postponing some nice things for later implementation — I still want Skila to look at least nicely. Ironically that easy subset is not that easy to grasp, currently I hit hard on nullable types. So far I could see three camps:

• C# — implicit null-check with null values (there are no referential non-nullable types though),
• Kotlin camp — explicit null-check with null values,
• Swift camp — as Kotlin but with wrapper class “Option” instead of null.

Take my words with grain of salt because I don’t know Kotlin or Swift.

Using “null” is not the same as having “Option”, the second can be wrapped as many times as you like when in case of the former you cannot wrap “null” into “null” — it is a value, not a wrapper.

On the other hand all checks designed for nullable type can be applied to non-nullable type, this is not true with optional types. For example one can blindly execute “x != null” check in Kotlin, while the analogous code in Swift requires “x” to be really an “Option”.

Worse, both Kotlin and Swift approaches bring problems to Skila, for example — how do you initialize objects of generic type? If I choose Kotlin solution how does inheritance tree look like for nullable types? And even if I choose Kotlin approach indeed I know that “Option” type will have to be added as well, so maybe add it right from the beginning… and so on and on.

Just to increase my confusion I found out some inconsistency in Kotlin:

open class Foo {
  fun foo() : Int {
    return 0;
  }
}

fun test<T : Foo?>(x : T) : Int {
  return x.foo() // (*)
}

fun main(args : Array<String>) {
  println(test<Foo?>(null))
} 

Compiler should demand “x!!.foo()” in line marked with “(*)”, but the code above compiles without any errors. And it worries me for Skila — those two ideas (generics with nullable/optional types) are not easy and it is hard to foresee (at least for me) all the problems with writing generic classes in practice.

If you are curious you can play online with both languages — playground for Swift and for Kotlin.

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>”.

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!

Weekend with virtuals and abstracts

What is love without tenderness? No matter how interesting or frustrating the courses are out there, I cannot work too long without polishing Skila. Since it was a bit like come-back weekend I focused on rather boring issues:

• added syntax for un-shadowing (un-hiding) the methods from the inherited class (as I announced previously),
• the “new” modifier works the same way as in C#. However Skila raises an error, not a warning, if it is missing,
• there is “abstract” class (cannot be instantiated) and “virtual” one (all methods become virtual).

Plus some implementation details to check whether abstract method has a body, or non-abstract does not have any body, and so on. That‘s why I wrote “boring” — nothing spectacular here, but this work had to be done.

Next weekend looks way more interesting though — spécialité du chef on the horizon! First of all I plan to introduce exposing methods from a field of the class — thanks to it writing wrappers in container class will no longer be necessary, they will be generated automatically. Even bigger feature I have in mind — pinned constructors and “SELF” which would behave like implicit generics. Read more about the latter in the previous post I wrote.

For some time now this blog is under constant spam attack advertising losing weight. I have some respect for nowadays spammers, they got clever — every time the message looks absolutely legitimately, and the only trace of the spam is the spammer signature or nickname. The ironic fact is that for several years I wasn’t able to lose weight, but this year is different — thanks to strict (but tasty) diet which I came up with by myself and added body training from “Convict Conditioning” by Paul Wade I lost unwanted kilograms in 2 months and now I am good. So thank you spammers, I’ll pass.

Inheriting methods — almost there

The last two weeks were dominated by upgrading to LALR(k) parser — I did very little from Skila TODO list, but something anyway. I almost finished dealing with methods inheritance – so far Skila supports the same model as in C#. I have one bug to hunt and one optimization to make (skipping creating empty virtual table). I don’t allow multiple class inheritance, however in general I would like to add it but without much expense. So this feature is on hold.

I rewrote generating classes and methods in the backend — now classes are pure structures (fields only) and methods are functions with extra argument this passed. Of course I had to write custom dispatcher for virtual methods — it was easier than I thought, one step less for porting the backend to JS and R.

It was great opportunity to refresh my knowledge about C# — I didn’t know that interface method declaration is implemented as a method with empty body — and while doing so my patience for two C# books I have ran out. Each time I try to get definitive answer all I find is either the story from the same as me author who feels the urge to patronize me, or mumbling over 8 pages about the given concept. Polish editions of C# in Depth by Jon Skeet and Pro C# 2010 and the .NET 4 Platform by Andrew Troelsen are for sale sold.

The incoming features are standalone functions and finding new angle for handling the data — something between C++, C# and Go. I am thinking of automatic de-/referencing the objects (this would mean no overloading based on pointer depth) with struct defaulting to data and class defaulting to non-null pointer to data — each default could be explicitly overridden though. We’ll see…