Results, Exceptions, and Custom Effects

[MrJohz]

Hi, I've been playing around with Koka a lot recently, and it's been great, if a bit mindbending at times!

I'm writing a basic AST-walking interpreter, and I've got some stuff in there that's fallible — for example, missing functions, or calling things with the wrong number of arguments. Currently, I make a lot of use of the either type to handle these sorts of cases — either we can evaluate the AST and get a result (Right), or something went wrong (Left).

Dealing with these either values can be a bit of a pain at times, and I know effects can often replace monadic structures, so I've looked a bit at the exn effect as an alternative, but as far as I can tell, I lose a lot of type safety that way, because I only have access to the exception type. Alternatively, I could write my own exception-like effect, but that feels like it would be tedious at a larger scale.

What sort of patterns are recommended, or at least have been tried out so far? Is it expected that people will mostly stick to the exn effect, or that the either type should be the error-handling bread-and-butter?

[TimWhiting]

For domains specific exceptions it is often appropriate to create your own exception effect which allows you to ensure that you are catching only your kind of exception where you want to handle it, and not any other types of exceptions, as well as any other domain-specific exit behaviors.

However, that being said, you'll notice that throw takes an optional argument exception-info, of which there are a few variants (and you'll notice it is an open type).

// The exception data type
pub value struct exception( message :string, info :exception-info )

// Exception information
pub open type exception-info
  ExnError      // Generic error
  ExnAssert
  ExnTodo
  ExnRange
  ExnPattern( location : string, definition : string )
  ExnSystem( errno : int )
  ExnInternal( name : string )
  
// Throw an exception with a specified message.
pub fun throw( message: string, info : exception-info = ExnError ) : exn a
  throw-exn(Exception(message,info))

To define your own variants of an open type you can do:

extend type exception-info
  UnboundVariable(name: string)
  NumArgsError(fn-name: string, expected: int, actual: int)

// And then you can create your own try / catch that catches only your variant/variants
fun catch-num-args(f: () -> <exn,exn|e> a, hndl-num-args: (string, int, int) -> <exn|e> a): <exn|e> a
  try(f) fn(ex)
    match ex.info
       NumArgsError(nm,e,a) -> hndl-num-args(nm,e,a)
       _ -> throw-exn(ex)

This creates two new constructors for exception-info.
It is impossible to do a complete pattern match on an open type, so you have to provide some default case, or deal with an exception from an incomplete match. In this case it makes the most sense to have a default behavior of re-throwing unrelated exceptions.

You'll notice two exn effects in f's function type. This is because there are at minimum 2 exn handlers in the stack above f. One is installed by the try function, which delegates to our callback for handling. And the other needs to be above our function to catch any errors we rethrow using throw-exn(ex).

[TimWhiting]

You can use final ctl to denote that the effect operation never returns. Also make sure that the return type is polymorphic & unrelated to the polymorphism of the effect itself.

pub effect fail<b>
  final ctl fail(info: b) : a

or even more clearly

pub effect interp-failure
  final ctl unbound-var(name: string) : a
  final ctl invalid-num-args(expected: int, actual: int): a 

In this case you can handle the failures differently, though since they are both final ctl neither can resume.

[TimWhiting]

As far as either, I would say that it really just depends. I personally would lean into the effect system as much as possible, especially if the knowledge of how to handle the error is high up the call stack. Strongly typed effects makes certain that you won't forget to handle the error at some point. That is both an advantage and disadvantage. As you saw with exn some other closure / function might capture & handle your error if you are not careful. However the masking section of the documentation can help with being careful about this: https://koka-lang.github.io/koka/doc/book.html#sec-mask. Also, you can create your own effect operations that do not resume really easily.

As far as optimization: do annotate non-resumptive clauses as final ctl, there is potential for optimization there, though I'm uncertain if Koka currently takes advantage of it. Also even though the exn effect marks its operation as ctl, you'll notice that try marks it as final ctl. You can mark an operation as more restrictive when handling it than is available in the effect declaration. However, there are fewer optimizations available this way since they have to be runtime optimizations, instead of known statically. So make the effect declaration as strict as possible. (final ctl or fun or val instead of ctl or raw ctl). I think the default of ctl in the regular exception effect is a mistake.

[chtenb]

One could even go as far as writing

pub effect final ctl unbound-var(name: string) : a
pub effect final ctl invalid-num-args(expected: int, actual: int): a 

Having a separate effect for each case allows you to only handle the cases that actually occur. Larger effects (and error sum types for that matter) bear the disadvantage that you always have to handle all of them, even though some code paths are guaranteed to only ever return one case.

[MrJohz]

That doesn't seem to work quite as I expect. As an example:

effect final ctl err-not-found(name: string): a

fun error-handler(eval: () -> <err-not-found|e> int): e string
  with final ctl err-not-found(name) "function not found: " ++ name
  eval().show

There may be more errors with the code, but the one I'm running into that looks like a compiler error is this:

$ koka error.kk
compile: error.kk
... snip loading ...
check  : error
*** internal compiler error: Type.Infer.checkCoverage: illegal operation field name: final ctl-err-not-found in error/@Hnd-err-not-found

Removing the final modifier from the effect declaration seems to fix this. The final modifier on the handler can be added or removed. I assume this is a compiler bug of some description, at least based on the error.

[TimWhiting]

Yeah, that is definitely a compiler bug, just added an issue for it: #456