`return` with no `else` — no more papercuts

I understand this or that omission in given language — not enough resources, somebody was not bitten by specific error, but it is strange when you see on multiple occasions a guideline which goes against software safety. Consider such code:

def foo() Int
  if x > y then
    return 17;
  end
  return 44;
end

Such code is legit in every language I know, what’s more it is advised way to write according to Mozilla guidelines and Go as well ¹. I admit it is more pleasing for the eye than version with added explicit `else`, but when it is time to refactor the code it is way too easy to make a stupid mistake like this:

def foo() 
  if x > y then
    my_flag = 17;
  end
  my_flag = 44;
end

I noticed it because I was hit by it — you don‘t have clear mind all the time. And since Skila is designed to prevent exactly this kind of errors (“stupid mistakes”) I am about to add not even an opposite guideline, but simply a check — any flow interruption instruction has to be followed with `else` branch. Safety first.

---

¹ Read more: “No-else-after-return” considered harmful, Effective Go.

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…