All the noise about static

Who would thought that adding “SELF” can cause so much fuss — obviously I needed “static” notion in Skila, which I hadn’t have and when I added it appeared NLT parser is not suitable for new set of parsing rules.

The last problem came as no surprise — so far NLT forking parser executed all user actions, even in multiple branches. This had to lead to problems and hit me this weekend. So instead of doing fancy stuff with pinned constructors, I sat down and changed executing user actions into logging parser actions. On successful parse, all commands are played back and then user actions are executed.

No rocket science, nevertheless I was one day short, and after adding exposing field’s methods feature plus fixing PHP backend a bit I ran out of time. I plan to squeeze error reporting on static misuse into workdays so I will be able to come fresh to implementing pinned constructor and “SELF” next weekend.

Advertisement

Exposing field’s methods

At least this feature I made on time as planned — similarly to un-shadowing the hidden methods, you can expose field’s methods. From time to time I have to either expose entire field (bad, but I am lazy) or I have to manually write a bunch of proxies — this is gives solid code but it is bad as well, because not productive. For fast prototyping, or for cases when you just need few methods from a field — exposing is the best pick. For example:

def main() Int
do
  var bar = new Bar();
  return bar.single();
end

struct Foo 
  def single() @Int = 1;
end

struct Bar 
  var foo Foo = new Foo();
  using foo.*;
end

The last directive — “using” — exposes given methods. This particular call is maybe an overkill because it exposes all methods, but is up to user which variant she/he uses. There are 3 more:

  using foo.single(*);
  using foo.single();
  using foo.single;

As one can see they are consistent with un-shadowing — from the first to the last one, we see exposing all “single” methods, exposing one particular “single” method (here: parameterless), and exposing “single” method under condition there is only one.

The call “bar.single()” is correct because Skila compiler automatically creates a proxy method for every “using” directive. Maybe in future it will be optimized and such call will be simply translated (redirected in compile time). However as we know “premature optimization is the root of all evil” so I’d better move to other, still green, pastures…

All little Saturday things

I confess — I am a traitor. Over a week ago I enrolled in Coursera course “Discrete Optimization” by Prof. Pascal Van Hentenryck and it is frustratingly interesting if I may say that. Since I love computational challenges I was hooked in since the first assignment. I tried to keep the weekend only for Skila, but I failed — writing one thing, and thinking about other makes no sense, so I switched and worked on DO almost entire Sunday. But don’t despair, I am a thorough guy, I wrote down how many hours I borrowed from Skila.

It doesn’t mean I did nothing — however only a little additions and improvements:

• I optimized backend in case of non-virtual types (simply no virtual table),
• in backend layer interfaces are classes with empty methods — this allows to safely call a method when derived class hides it,
• I added standalone functions — this required surprisingly some work,
• I already mentioned covariance when it comes to polymorphic methods,
• Skila supports 4 types of expressing the base for numbers like in Python — “124” for decimal, “0xCAFE” for hexadecimal, “0o57” for octal and “0b010101” for binary,
• numbers can be expressed with padding as in Ruby — “450_010” is exactly the same as “450010” only reading is easier,

Next point is exposing back shadowed methods — I have in mind three cases:

using base::foo(Int);
using base::foo(*);
using base::foo;

The first one brings up method foo with given signature, joker “*” in the second line brings all foo methods. And third one is a shortcut — if there is only one method foo in inherited class it will be brought up. If there are more — compiler will give you an error.

And that’s all for the Saturday, I am running back to DO assignments…