Tink is not working?

[deathbeam]

Hey everyone. I am building my own programming language on top of Haxe, and I want to use Tink to ease some parts of it. For example implicit returns. This is code generated by my language compiler. As you can see, it is inserting @:tink before class name. But it is not working and Haxe compiler is throwing error where Tink should recognize the implicit return.

package raxe;using Lambda;using StringTools;import mcli.Dispatch;
import raxe.cli.Cli;

@:tink class Main{

static dynamic public function main(){
  trace(test());
  var args = Sys.args();
  Sys.setCwd(args.pop());
new   Dispatch(args).dispatch(new Cli());
};

static dynamic public function test() {
  "Hello";
};
}

My hxml looks like this:

-cmd haxelib run raxe -a -s src -d build
--next
-lib mcli
-lib hscript
-lib tink_lang
-cp build
-main raxe.Main
-neko run.n

So, am I doing something wrong?

[back2dos]

I'm not convinced it should actually make an implicit return here. How would one otherwise write a function that returns nothing?

If you want all functions to return implicitly, you should simply always generate a return statement, e.g.:

class Main {

  static dynamic public function main() return {
    trace(test());
    var args = Sys.args();
    Sys.setCwd(args.pop());
    new   Dispatch(args).dispatch(new Cli());
  };

  static dynamic public function test() return {
    "Hello";
  };
}

[deathbeam]

And how then implicit returns in Tink work?

[fullofcaffeine]

Tomas, just a wild idea, couldn't implicit returns be supported by adding a
return automatically at the time the Raxe code is transpiled to Haxe,
instead of using Tink at the Haxe level?

On Fri, Oct 2, 2015 at 2:20 AM, Tomas Slusny notifications@github.com
wrote:

And how then implicit returns in Tink work?

—
Reply to this email directly or view it on GitHub
#19 (comment).

[deathbeam]

@fullofcaffeine This is not the right place to talk about Raxe. And yes, sometimes it is possible, but sometimes it isn't, and I am afraid that there are a lot places where it isn't possible. I can close this issue here then, because as it seems, implicit returns do not works everywhere where it works in languages what have implicit returns, what is a pity :( Okay, closing.

[back2dos]

@deathbeam Yes, I can see how the documentation might be misleading. I will reopen this issue and close when I've had time to improve it. The short version: tink uses implicit returns in the places where it is absolutely clear that the function must return something, and currently that's only accessors. I should probably extend that to functions that define a return type.