Re: [Bug-apl] Error handling and IO

[Kacper Gutowski]

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
  ^ ^
  →

Re: [Bug-apl] Error handling and IO

[Elias Mårtenson]

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  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
>   ^ ^
>   →
>

Re: [Bug-apl] Error handling and IO

[Juergen Sauermann]

  
  
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 
  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
      ^ ^
      →
  


  


  

Re: [Bug-apl] ⎕SQQ

[Juergen Sauermann]

Hi Kacper,

thanks, fxed in *SVN 719*.

/// Jürgen


On 04/10/2016 03:43 AM, Kacper Gutowski wrote:

Hi,

Currently GNU APL doesn't know what ⎕SVQ is because it
became ⎕SQQ due to typo back in r625.

   ⎕SVQ''
VALUE ERROR
   ⎕ SVQ ''

Amusingly:

   ⎕SQQ
SYNTAX ERROR
   ⎕SVQ
   ^

-k

Re: [Bug-apl] Error handling and IO

[Elias Mårtenson]

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" 
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  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
>>   ^ ^
>>   →
>>
>
>
>

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"

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 
  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

Re: [Bug-apl] Error handling and IO

[Kacper Gutowski]

If I understand correctly, Elias wants to have something that would
ensure that every file opened is eventually closed (only more general so
it can be applied to any external resources not only files).  That is in
a code similar to the following, to ensure the line 3 is always run even
if there's an error in FUN.

[1] FD←⎕FIO[3]STH
[2] FUN FD
[3] ⎕FIO[4]FD

This can be ensured by wrapping FUN call with ⎕EA or ⎕EC.  They return
to the caller instead of suspending execution if error happens and this
is correct and expected behaviour.  But the intention is to have the
file closed, not making the function unsuspendable, so this would be
a side effect of the solution of using ⎕EA rather than the intended
behaviour.  But this doesn't mean there's anything wrong with ⎕EA or
⎕EC, of course.

My understanding is that requested is some way to associate some kind of
clean up code with )SI entry that would be run upon that entry being
cleared from )SI regardless of how that happens.

The way I imagine it, it could look like this (using an imaginary
function ‘defer’ with a name borrowed from Golang; not an actual
transcript):

  ∇ FOO
[1] FD←⎕FIO[3]STH
[2] defer '⎕FIO[4]FD'
[3] FUN FD
[4] other stuff ∇

  STH←'filename'
  ⎕FX 'FUN F' '1+'

  FOO
SYNTAX ERROR
FUN[1]  1+
^^
  ⍝ here situation can be examined
  )VARS
F   FD
  )SIS
FUN[1]  1+
^^
FOO[3]  FUN FD
^
⋆  FOO
   ^
  →
  ⍝ here ⎕FIO[4]FD is executed

-k