Chapel: `Try/Catch` not working with First Class Functions

[krishnadey30]

Try/Catch is not working with FCF's.

Code to reproduce the error

proc raiseError() throws {
  throw new owned IllegalArgumentError();
}

var temp = raiseError;
try { temp(); }
catch { writeln('Caught an error'); }

Output

uncaught IllegalArgumentError: 
  fcf.chpl:2: thrown here
  fcf.chpl:6: uncaught here

[ben-albrecht]

This is a gating issue for developing a prototype of #13098.

[LouisJenkinsCS]

I am hoping that this gating issue will usher in a dawn of brighter and better First Class Functions in Chapel.

[bradcray]

This is unfortunate, though not terribly surprising. FCF's were implemented by a summer intern and have never received much official attention, so probably were not considered when error-handling was added in. I don't know whether fixing this would be a significant or simple effort. I think @mppf might be able to say.

[mppf]

It was a relatively simple effort and I completed it 40 minutes ago :)
(PR #13197)

I am hoping that this gating issue will usher in a dawn of brighter and better First Class Functions in Chapel.

That would not be a simple effort.

[bradcray]

I completed it 40 minutes ago

That'll teach me to ignore all of those little GitHub status change messages that my eye usually looks right past! (except that, more likely, it will not)

[LouisJenkinsCS]

I still want better FCF support :(

[mppf]

@LouisJenkinsCS - I'm not sure that will be a priority for me personally soon, but the next steps are to make progress on the language design. #8351 is a good jumping off point if you want to think about the language design questions.

[bradcray]

I still want better FCF support :(

We know, we know... You want pretty much everything to be done and optimized simultaneously which unfortunately isn't possible or realistic.

[LouisJenkinsCS]

We know, we know... You want pretty much everything to be done and optimized simultaneously which unfortunately isn't possible or realistic.

To be fair, I want the _ability_ to perform my _own_ optimizations, which is why I generally ask for lower-level stuff (I.E as part of multiresolution design philosophy). Even if the initial implementation of X is inefficient, I'd want to be able to experiment and leverage the infrastructure that X is built on, instead of being forced to solely rely on X. In this case, there is no way to manipulate runtime functions, or compiler __primitive calls, or anything to enable the kind of first-class function support I'd desire.

To use a concrete example, I wanted to enable UPC++'s asynchronous-style computation in Chapel via futures and non-blocking calls. I didn't _ask_ for futures, just non-blocking low-level primitives so I could _implement it myself_, as a means of not burdening you guys with a huge request like "Implement UPC++ futures in Chapel please!". Instead, I'm asking "Give me a way to implement UPC++ futures in Chapel, please".

[bradcray]

My frustration, and the nerve you've touched here, is around when GitHub issues are used as though they were chat forums or places to vent or hammer on well-covered points rather than staying focused on what the issue was opened for. This issue was about try/catch not working with first-class functions. To me, these posts aren't constructive w.r.t. the topic at hand and would be better suited someplace else.

[LouisJenkinsCS]

Gotcha. If I had the ability to mark my own comment as 'off-topic' that'd be nice (as well if you think my comments are off-topic, feel free to mark them as such as well)

Edit Nevermind found I can do it by Hiding it! Cool!