Monthly Archives: July 2013

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.

Tagged , , , ,

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…

Tagged , ,

The syntax of accessing static elements

Until now, I didn’t realize how twisted is the history of design of such little feature. In C++ you can access static elements from an instance or a type:

my_obj.InstanceField;
my_obj.StaticField;
MyType::StaticField;

Not bad, but of course Java guys had to simplify things:

my_obj.InstanceField;
my_obj.StaticField;
MyType.StaticField;

C# designers noticed there are too many dots here, and there is too little difference between the first two calls so… they removed external access to type element from an instance. The only options available are:

my_obj.InstanceField;
MyType.StaticField;

And this is the worst choice you could make, because sometimes all you have is an instance (object) and you have to jump through some hoops just to get the type of instance.

Skila brings sanity back:

my_obj.InstanceField;
my_obj::StaticField;
MyType.StaticField;

Such syntax is consistent with accessing namespace elements (Skila borrows it from C#, not C++) and it also improves readability — when you access an element via an instance by looking at next symbol (dot vs. colon) you can say whether it is a type or an instance element. One can think of a dot as the same level access (type to type, instance to instance) while double colon serves as cross level access (instance to type).

Tagged , , ,

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.

Tagged , , , , ,

Implicit generics and pinned constructors

It is preliminary step of enhanced generics we know from C# and I hope all things finally clicked in for implementing this feature. Consider such code:

public class ClassModifier : TreeNode
{
  public bool IsAbstract { get; private set; }
  public bool IsVirtual { get; private set; }
  public bool IsStatic { get; private set; }

  private ClassModifier(NodeCoords coords)
    : base(coords)
  {
  }

  public static ClassModifier Abstract(NodeCoords coords)
  {
    return new ClassModifier(coords) 
      { IsAbstract = true };
  }
  ...

and

public class MethodModifier : TreeNode
{
  public bool IsAbstract { get; private set; }
  public bool IsVirtual { get; private set; }
  public bool IsStatic { get; private set; }
  public bool IsNew { get; private set; }
  public bool IsOverride { get; private set; }

  private MethodModifier(NodeCoords coords)
    : base(coords)
  {
  }

  public static MethodModifier Abstract(NodeCoords coords)
  {
    return new MethodModifier(coords) 
      { IsAbstract = true };
  }
...

Factory methods as usual, nothing special except the code is highly redundant. In PHP it can be expressed nicely because it has static constructor with late binding — it works like static polymorphism. It can be shortened in C# too, but with ugly twists.

However Skila is meant to be expressive and compiled language.

So I came up with idea of pinned constructor for the beginning. Once added to any class such constructor has to be overridden in every descendant class (or automatically upgraded). Secondly special keyword to express static polymorphism is needed — “SELF” sounds just right. With those two enhancements the code becomes much shorter (it is not Skila yet):

public class ClassModifier : TreeNode
{
  public bool IsAbstract { get; protected set; }
  public bool IsVirtual { get; protected set; }
  public bool IsStatic { get; protected set; }

  protected pinned ClassModifier(NodeCoords coords)
    : base(coords)
  {
  }

  public static SELF Abstract(NodeCoords coords)
  {
    return new SELF(coords) 
      { IsAbstract = true };
  }
  ...

public class MethodModifier : ClassModifier
{
  public bool IsNew { get; private set; }
  public bool IsOverride { get; private set; }
  ...
}

Thanks to pinned constructor it is safe to write “new SELF(coords)” — every class has to support such call. And because “SELF” works as implicit generics when I call “MethodModifier.Abstract()” I will get “MethodModifier”, not “ClassModifier” despite the fact the method is static and it is defined in “ClassModifier” class.

Tagged , , , , , , ,

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…

Tagged , , , , , , , , , , , ,