Re: [Bug-apl] Error handling and IO

[Juergen Sauermann]

Hi Elias, what is a handler in this context? In the cases of ⎕EC and ⎕EA the behavior is defined so that they unwind the stack when an error has occurred and return some information regarding the error to the caller. APL execution always happens in the lowest )SI entry, so you cannot continue APL execution before the stack is unwound. In theory one could copy some more information (current statement and PC) so that ⎕EM looks a little better, but the behavior as such should remain as is. On the other hand, there is a statement in the APL2 lrm saying (p. 281): ⎕EM and the State Indicator: ⎕EM contains the event message associated with the top line of the state indicator. As the stack is cleared (with → or )RESET n), ⍎EM is reset to the event message associated with the current top line of the state indicator. That is the current GNU APL behavior. In my APL2, ⎕EM is broken when used with ⎕EA:      '⍳ì3' ⎕EA '⍳4.5' 1 2 3       ⎕EM DOMAIN ERROR                      ↑(0??0(0 0))+0??(0 0)0                     ^^      /// Jürgen On 04/11/2016 06:41 PM, Elias Mårtenson wrote: In Lisp, the stack is not unwound until until after the handler has had the opportunity to run. This means that all local state of the failed function is still available to the handler. Would this make sense to implement in GNU APL too? On 11 Apr 2016 23:26, "Juergen Sauermann" <juergen.sauerm...@t-online.de> wrote: Hi, not sure what is meant by "having the ability to get suspension"? My understanding of ⎕EA and ⎕EC is that their primary purpose is to prevent suspension and instead to return to the caller. Returning to the caller implies unwinding of the )SI stack, and a consequence of unwinding )SI is that the statement in which the error has occurred has been unwound with it. Unwinding the stack could very well remove the defined function in which the error had occurred, for example if you did, for example ⎕FX of a local variable in order to create a local function). That is the main reason why lines 2 and 3 of ⎕EM are gone - there is no guarantee that the offending statement still exists. /// Jürgen On 04/11/2016 09:24 AM, Elias Mårtenson wrote: One option would be to have a way to install a callback that is called when a stack frame is unwound. This could be provided to the plugin API, providing the needed infrastructure to the FILE_IO module. Regards, Elias On 11 April 2016 at 15:07, Kacper Gutowski <mwgam...@gmail.com> wrote: On Mon, Apr 11, 2016 at 5:27 AM, Elias Mårtenson wrote: > This seems similar to what GNU APL provides with the ⎕EA feature. The > problem with this (and, as far as I can tell, also with this Dyalog feature) > is that in an error handler, the original error has disappeared. If you call some function inside ⎕EA or ⎕EC and then do the clean up, the only thing you loose is the ability to get suspension inside it.  The original error type and message is still available in ⎕ET and ⎕EM after ⎕EA or directly returned by ⎕EC.  Sadly, the second and third lines of ⎕EM showing location where the error occured seem indeed to be left out. Perhaps this could be improved.  But if you pass it to ⎕ES, it will simply appear as if said function were fixed as not suspendable,* which makes sense to some degree because it's not possible to suspend it under ⎕EA or ⎕EC. Having ability to get suspension and then appropriate resources freed on unwind regardless if it happens normally, after user's corrective action, or by clearing stack indicator would be pretty cool, but that sounds like a big leap in the way stack indicator works. -k *Compare:       ⎕FX 'y F x' 'y+x' F       F 1 VALUE ERROR F[1]  y+x       ^       →       0 1 0 0 ⎕FX 'y F x' 'y+x' F       F 1 VALUE ERROR       F 1       ^ ^       →       ∇R←(F G) x [1] ⎕ES 0 0 ⋄ ''⎕EA'R←F x' [2] ⍝ cleanup here [3] (,1↑[⎕IO]⎕EM) ⎕ES ⎕ET  ∇       {⍺+⍵}G 1 VALUE ERROR       G 1       ^ ^       →