[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-apl] Error handling and IO

From: Juergen Sauermann
Subject: Re: [Bug-apl] Error handling and IO
Date: Mon, 11 Apr 2016 20:13:50 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0

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

That is the current GNU APL behavior. In my APL2, ⎕EM is broken when used with ⎕EA:

     '⍳ì3' ⎕EA '⍳4.5'
1 2 3
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" <address@hidden> wrote:

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.


On 11 April 2016 at 15:07, Kacper Gutowski <address@hidden> 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

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.



      ⎕FX 'y F x' 'y+x'
      F 1
F[1]  y+x

      0 1 0 0 ⎕FX 'y F x' 'y+x'
      F 1
      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
      G 1
      ^ ^

reply via email to

[Prev in Thread] Current Thread [Next in Thread]