Supporting return in blocks

[tillda]

I'm pretty skilled in both JS and Ruby, so I was wondering how would you compile this:

def find_even iterable
  iterable.each { |x| return x if x % 2 == 0 }
end

puts find_even [1, 3, 5, 6]
#6

It seems to me pretty tough to do both blocks and functions in JS and if I'm trying it right it doesn't work for me (it should return 6).

Any plans or thoughts on that?

[elia]

Related: #135

[elia]

Related: #135

[charliesome]

You'd probably need to use an exception here - at least that's how I implemented this in my experimental Ruby to PHP compiler

[charliesome]

You'd probably need to use an exception here - at least that's how I implemented this in my experimental Ruby to PHP compiler

[meh]

AFAIK there was support for this, there's probably a bug in the optimization recognition.

[meh]

AFAIK there was support for this, there's probably a bug in the optimization recognition.

[adambeynon]

As @charliesome says, to get full functionality, exceptions needed to be used, which really is a pain (in terms of ugly code generation and whatever performance losses on the blocks). Its one of those areas where Im trying to look for a better solution. The generator could follow the method of detecting break. This just checks the return values of blocks, and may be able to optimize a block return without exceptions in the majority of cases. Will look into it anyway.

[adambeynon]

As @charliesome says, to get full functionality, exceptions needed to be used, which really is a pain (in terms of ugly code generation and whatever performance losses on the blocks). Its one of those areas where Im trying to look for a better solution. The generator could follow the method of detecting break. This just checks the return values of blocks, and may be able to optimize a block return without exceptions in the majority of cases. Will look into it anyway.

[adambeynon]

Realistically this isnt going to be implemented by Opal, as raising/catching exceptions would be the only ideal way to do it, and thats not really ideal itself. In this specific instance, you could use Enumerable#find instead. Might reopen one day if some other clever way of handling this statement comes up.

[adambeynon]

Realistically this isnt going to be implemented by Opal, as raising/catching exceptions would be the only ideal way to do it, and thats not really ideal itself. In this specific instance, you could use Enumerable#find instead. Might reopen one day if some other clever way of handling this statement comes up.

[charliesome]

If I get around to it, I might try and implement this. It will require exceptions, but some trickery can be done so that we only need the try/catch for the few blocks that will return early.

FWIW, this is implemented in MRI with setjmp/longjmp - which is basically the C equivalent of exceptions.

[charliesome]

If I get around to it, I might try and implement this. It will require exceptions, but some trickery can be done so that we only need the try/catch for the few blocks that will return early.

FWIW, this is implemented in MRI with setjmp/longjmp - which is basically the C equivalent of exceptions.

[adambeynon]

Inside the parser, @scope is the current scope, so if a return is detected, we could mark it there so we know if we do need to add a try/catch loop inside the method body. That does sound a nice enough solution. An error is created in runtime.js for breaks (even though theyre not implemented with exceptions anymore), so adding a hardcoded one for returns is probably a good idea too.

Foo.prototype.$method = function() {
  try {
    // block raises __opal.return_err
  }
  catch (err) {
    if (err === __opal.return_err) {
      return err.$v;
    }
    throw err;
  }
};

[adambeynon]

Inside the parser, @scope is the current scope, so if a return is detected, we could mark it there so we know if we do need to add a try/catch loop inside the method body. That does sound a nice enough solution. An error is created in runtime.js for breaks (even though theyre not implemented with exceptions anymore), so adding a hardcoded one for returns is probably a good idea too.

Foo.prototype.$method = function() {
  try {
    // block raises __opal.return_err
  }
  catch (err) {
    if (err === __opal.return_err) {
      return err.$v;
    }
    throw err;
  }
};

[charliesome]

This is basically what I was thinking of doing. Should I have a crack at it?

[charliesome]

This is basically what I was thinking of doing. Should I have a crack at it?

[adambeynon]

Yeah, it is quite an elegant solution. If your happy to work on it, then go for it. Let me know if there is anything you need assistance with

[adambeynon]

Yeah, it is quite an elegant solution. If your happy to work on it, then go for it. Let me know if there is anything you need assistance with