Arc Forumnew | comments | leaders | submitlogin
2 points by almkglor 5826 days ago | link | parent

Some more things:

1. Continuation guards. Should we implement these? The current Arc prevents continuations from a different thread to be executed, as well as protecting continuations from outside 'on-err from being executed within the context of 'on-err.

This is reasonably easy to implement: just have a global "current continuation guard number". Newly created continuations are given that number. If a continuation is called, the current continuation guard number should equal that continuation's guard number. Otherwise we have a call to a continuation outside the guard.

'on-err and 'new-thread would then wrap the function call around something like:

  ; ccgn == current continuation guard number.
  (let foo (%ccgn)
    (%new-ccgn)
    (f)
    (%set-ccgn foo))
(Again, this is an argument for subtyping closures into continuation and non-continuation functions)

Of course this does have the overhead that whenever continuations are called, we have to do the comparison, and call the current error handler.

2. Error handling. Possibly we could just add to lib-ac.scm.arc:

  (set $default-err
       (fn (e)
         (%pr "Error: ")
         (%prn e)
         (%backtrace)
         (%halt)))
  ; TODO: make this a thread-local in the future!
  (set $curr-err
       (%cons $default-err nil))
  (set err
       (fn (e)
         ((%car $curr-err) e)))
  (set on-err
       (fn (ef f)
         ; <insert continuation guard handling code here>
         (set $curr-err (%cons ef $curr-err))
         (f)
         ; <insert continuation guard handling code here>
         (set $curr-err (%cdr $curr-err))))
Of course, there's the slight problem of how to handle errors reported by the primitives themselves, as well as the runtime system (such as continuation guards being violated, or doing (car #\newline)). We should call the current 'err error handler.

Also, in canonical Arc, the value received by an 'on-err error handler is an opaque "exn:fail" structure, which Arc cannot manipulate. Should we also emulate this structure?



1 point by sacado 5824 days ago | link

1- is interesting and important, thus it should eventually be done, but I don't think this is a priority right now.

2- is a good starting point. For exn:fail, that the same as for 1- : not a top priority, particularily as it is not yet implemented in canonical arc.

I'll work on error handling on the next days, as I'll have a little more time than last week(s).

-----