Allow Exception ability to be used by main functions

[pchiusano]

Prior to this PR, the main type has to be '{IO} (), now it can be '{IO,Exception} (), allowing unhandled exceptions to bubble to top level. If they make it there they should just act similar to as if you called bug on the failure. io.test command gets a similar upgrade.

See this transcript

Suggested by @rlmark and @stew.

Implementation notes

Right now, the implementation literally just allowing the exceptions to bubble up to the top of the runtime. This used to give a nice uncaught request message similar to if you called bug, but in the current runtime it yields:

.> run main2

  resolve: looked up bad dynamic: 48

Which is no good. We could either fix the runtime to generate a nice message in the case of uncaught requests, or wrap all calls to run in something like this:

catchOrCrash : '{Exception,g} a -> '{g} a
catchOrCrash a _ = handle !a with cases
  {a} -> a
  {Exception.raise ex -> _} -> bug ex

The thing is that I'd like to customize the message a bit, rather than just getting the default bug message. So I guess I'd lean toward fixing up the runtime if that's easily doable. @dolio WDYT?

Testing

I added a transcript to exercise this (and it currently succeeds with that poor error message). I think that should be sufficient testing once the error message gets sorted out.

[pchiusano]

@dolio Not urgent.

[dolio]

I think what's happening with the error message you get is that it's looking up the dynamically scoped raise implementation and not finding anything.

I think it should be possible to instead populate it with something that just throws an appropriate runtime exception that is caught with the other exceptions. If you use a different exception type than the one used for bug, you could do something different. But it might also be possible to just put the text you want in the raise implementation. It depends what exactly you want to be displayed.

[rlmark]

I've tested this locally and ran some terms with the type '{IO, Exception}() and had them succeed without needing to call an Exception handler at the top level!

When raising an exception I do see the resolve statement as the error, but it sounds like Dan is on it!

[pchiusano]

Next step on this @dolio - could you install a top-level handler for the Exception ability, so it can generate a nicer error message in this situation?

Something else I want to figure out is catching exceptions in pure code, and I wonder if they're related. Like what if bug / todo and other runtime exceptions just look for a handler of Exception, as in bug and todo are defined like -

-- a new builtin function which is just a cast
builtin Exception.unsafeRun : '{g,Exception} a -> {g} a

bug : a -> x
bug a = Exception.unsafeRun '(raise (Failure (typeLink Bug) "a bug" (Any a)))

todo : a -> x
todo a = Exception.unsafeRun '(raise (Failure (typeLink Todo) "a todo" (Any a)))

[dolio]

I'm not clear what direction these are for.

If "catch exceptions in pure code" means that unsafeRun just becomes a bomb like bug and todo currently do, then I think that's fine.

If "catch exceptions in pure code" means that there needs to be a way to catch bug/todo calls in pure code somehow, I don't know how to make sense of that.

(catch exceptions) in pure code vs. catch (exceptions in pure code). :)

[aryairani]

I think we should go in the opposite direction: if UCM knows that your main function transitively depends on todo or bug, then the normal run command should complain instead of starting the runtime.

[pchiusano]

I think we should go in the opposite direction: if UCM knows that your main function transitively depends on todo or bug, then the normal run command should complain instead of starting the runtime.

Hmm can you explain? Are you saying you shouldn't be able to run programs unless you can (statically) determine they don't call todo or bug? That's a very high bar...

[aryairani]

I think we should go in the opposite direction: if UCM knows that your main function transitively depends on todo or bug, then the normal run command should complain instead of starting the runtime.

Hmm can you explain? Are you saying you shouldn't be able to run programs unless you can (statically) determine they don't call todo or bug? That's a very high bar...

I was saying you shouldn't be able to run programs with the run command if they reference todo (nevermind about bug). You could still run them with some other command.

[aryairani]

But in the spirit of keeping the ticket minimal, let's just keep it to being able to run a program with unhandled Exception, although wouldn't it be nice to still have a command that didn't?

[pchiusano]

Yeah, agree, let's just keep this to installing a top-level Unison Exception handler (this is in addition to the Haskell exception handler) in the runtime. @dolio LMK if you need more info on that - I'd just add a commit or two to this existing PR.

I think this is lower priority than fixing up the new inference algorithm issues recently reported.

[pchiusano]

@dolio sweet! Can you merge trunk into this branch and fixup conflicts?

[dolio]

Yeah.

Do you have some idea about the error message? Right now it's just printing out the Failure value in a not particularly nice way. But I'm not sure how to make it much better.

[pchiusano]

@dolio yeah, I'd reword a bit just to use full sentences.

The program halted with an unhandled exception:

And then I'd pass a suffixed pretty-print environment to the runtime so it uses shorter names. I think you can make this change in HandleInput.hs:

      IOTestI main -> do
        testType <- eval RuntimeTest
        parseNames0 <- (`Names3.Names` mempty) <$> basicPrettyPrintNames0A
        ppe <- prettyPrintEnv parseNames0
        -- use suffixed names for resolving the argument to display
        let
            parseNames = Names3.suffixify parseNames0

I think change to

      IOTestI main -> do
        testType <- eval RuntimeTest
        parseNames0 <- (`Names3.Names` mempty) <$> basicPrettyPrintNames0A
        let parseNames = Names3.suffixify parseNames0
        ppe <- prettyPrintEnv parseNames

[dolio]

Hopefully this merge works. I was getting local warnings about AbsN not being a complete pattern even though it's declared as one.

[pchiusano]

@dolio if you do a stack clean locally that should fix the error you were seeing. Stack's compilation cache incorrectly fails to invalidate when you add a COMPLETE pragma I guess.

[dolio]

Nah, I'm using cabal, so it doesn't seem likely to be that. Maybe it also wasn't rebuilding the relevant file.

Is that pragma actually new? I didn't think it was.

[pchiusano]

Maybe cabal's compilation cache has the same bug? :)

The pragma was newly added to ABT.hs in trunk kinda recently yeah.