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…

Advertisement

Steal ideas while they are hot

Stealing does not come free — in my case new idea about syntax took it toll by causing reduce/reduce conflict in parser. And since my NLT parser could deal only with shift/reduce conflicts, i.e. it could fork on such conflicts, I had to sit down and add forking for reduce/reduce as well. Don’t get me wrong, I don’t complain, NLT is getting better and better, the only thing that worries me is fact I cannot fork time as well — the more I work on NLT, the less time is left for Skila itself.

And even more work in parser is on the horizon — forking can resolve conflicts pretty nicely but it is a slow method (especially if you work on VM). Having more than 1 symbol as lookahead could be faster, so I feel I end up implementing this as well. Funny, I am way beyond intrinsic motivation here, rather sense of duty.

Back to Skila. I was peacefully implementing detection of dead code — unused variables (done), unused values of expressions (done), unreachable code (done), and from near category, no return branches in functions (done) when I saw a piece of Go code. Namely short form of declaration and initialization:

hello := "some text";

I also noted “missing” colons between variable/parameter/function name and its type (naming is weird):

func (s string) Len() int

Wait, wait, wait! Could this be done to Skila? And why do I have to find such mind puzzles just before midnight?

First thing morning I changed Skila source codes to test how it looks and feels. Awkwardly (I already got used to Scala-like syntax), but… with every minute I liked it better. Well, after all most of the time I spent with C++ and C# and they don’t have colons as well. Let’s do it — this move cost me mentioned above problem with NLT parser, but it was worth it.

Colon takes (depending on the keyboard layout) from one to two keystrokes, it is disturbance in normal typing workflow. Also it takes some space. I predict that writing the code should be more fluent, I hope time will show I was right.

I didn’t drop full form declaration but changed its meaning — now Scala-like “var/const” is a statement, and Go-like short declaration is an expression (I was already looking for catchy syntax for it).

With such change (I felt in love with new syntax by then) finding a consistent way to mark method result to be read or not looks pale, but anyway — using just type name in function signature now means default mode. If the method is mutating you don’t have to read its outcome, if it is — you do. You can override it though:

def const_method() @Int
def mutator!() !Int

The first line reads — the method does not change the logic state of the object, and its result does not have to be read (by default it has to). The second line states — the method changes logical state of the object (exclamation mark next to function name — stolen from Ruby) but its result has to be read (by default it does not have to).

Weekend of the thief — to make me even more happy and to have a source to continue this shameless conduct I bought “The Ruby Programming Language” by David Flanagan, Yukihiro Matsumoto (I am already reading it), “Programming Clojure” by Stuart Halloway, Aaron Bedra and “JavaScript: The Good Parts” by Douglas Crockford.

Anything from bad news department? Yep — I have to overcome my Skila addiction for five long days…