Monthly Archives: March 2014

Hack — smooth evolution

One thing I like about PHP is its hosting ubiquity — you can start away for free. I wonder if Hack will become equally successful.

Hack is a new language from Facebook, and while its syntax does not give me chills:

<?hh
class MyClass {
  const int MyConst = 0;
  private string $x = '';
  public function increment(int $x): int {
    $y = $x + 1;
    return $y;
  }
}

it simply might be good enough to gain acceptance. It is very interesting for sure, and Facebook prepared its website well, there is a interactive tutorial which looks rather like a mini course, and it is fun too.

One thing surprises me — with such effort and solid features, such a lame name? Somebody missed the lesson of “Go”.

Tagged , , ,

C++ const – how to make it happen?

The latest list of changes (not done yet) includes regular constructor (not returning anything), variadic syntax as in Go (“x ...Int”) and “procs” (for mutating methods) and “funcs” (not mutating, can be prefixed with “|”).

This is related to C++-like “const” ¹ — I am that guy who loves this feature (maybe not execution), however I am both a bit clueless how to implement it correctly and I am a bit afraid if I understand the concept (considering almighty MS gave up on this having so many smart people). I think there could be only two constants — constant pointer to some data (constant or not) and deep constant data (immutable view of data).

It might sounds funny but I don’t even have good names for them — say “lnk” for fixed pointer (“ptr” for regular one), but what for data? If possible I would like avoid “const” (to avoid naysayers with standard “it does not guarantee the object is constant after all”, and to keep good keyword for constants like mathematical Pi). “view”?


¹ Interesting posts at SO: Why there is no const member method in C# and const parameter?, Why const parameters are not allowed in C#? and “const correctness” in C#.

Tagged , , , , , ,

Dropping features — multi dispatch functions

The easiest part is removing missing features like multi dispatch functions. My recent discovery of Nimrod language gave me a lot to read — it is very likely I will copy the memory model of it.

However one thing for now I consider as no-go — multi dispatch methods (multi-methods). With single dispatch you can say the object owns the function, and thus owns the call (no such ownership with regular, standalone, functions, but there is no problem either, because there is no dynamic dispatch). Thanks to that the function you think should be called will be called, it is guaranteed by the object (owner).

There is no guarantee with multi dispatch — you see some call, and you cannot tell (by looking at the call) what function will be called. The only safe situation is if compiler gives you an error saying at compile time that it cannot resolve the call in any possible way — except for this you have to pay close attention what modules you imported, one less, one more, and the resolution will be altered.

In other words — call resolution is not dependent on the line with call, but on import section. The design I am not willing to see in Skila.

Another change in design is decorating mutable methods — I copied the idea from Ruby, but now I changed it a bit after pondering on pair of “get” and “!set”. It is ugly, plain and simple. Thus you decorate the immutable methods which have mutable counterparts. This gives you nice “get” and “set”, and also “reverse” and “|reverse” (the decoration character can be changed in future). Because of this now all the function results are by default required to read, there is no longer symbol to make them required because they are already. So, another simplification.

The current decoration symbol is chosen on purpose to resemble Unix shell:

  var processed = data | sort() | reverse();
Tagged , , , ,