Re: [Bug-apl] Error handling and IO

2016-06-23 Thread Louis de Forcrand
Hi Elias, If I understood your solution correctly, it basically boils down to the (correct, as far as I can tell) assumption that, for every block of adjacent face-down pancakes, you need two flips: - one to flip all the pancakes up to the first face-down one - one to flip the whole block of now

Re: [Bug-apl] Error handling and IO

2016-06-22 Thread Elias Mårtenson
No, actually not. The problem statement says that the final state of the pancake stack should be that they are all facing up. Thus if the final state is 0,there needs to be an extra flip done. Regards, Elias On 23 Jun 2016 02:25, "Juergen Sauermann" wrote: > Hi, > > a minor bug below: > > *

Re: [Bug-apl] Error handling and IO

2016-06-22 Thread Juergen Sauermann
Hi, a minor bug below:   +/(X,1)≠(1↑X),X←1 1 1 0 1 1 1 1 1 0 0 0 1 0 0 1 0 0 0 0 8   +/(X,1)≠(1↑X),X←1 1 1 0 1 1 1 1 1 0 0 0 1 0 0 1 0 0 0 1 8 Maybe you meant   +/(X,¯1↑X

Re: [Bug-apl] Error handling and IO

2016-06-21 Thread Elias Mårtenson
I've CC'ed the gnu-apl list with my answer to Christian's question, since I think this is an interesting discussion. For the newcomers, this is about the solution to this Codejam question: https://code.google.com/codejam/contest/6254486/dashboard#s=p1 It's quite simple actually. The idea is simply

Re: [Bug-apl] Error handling and IO

2016-06-21 Thread Juergen Sauermann
Hi coming back to an earlier discussion, I have added ⎕EB ("Execute Both") to GNU APL. A ⎕EB B is similiar to A ⎕EA B in that it first executes B. However, unlike ⎕EA which executes A only when B fails, ⎕EB always executes A regardless

Re: [Bug-apl] Error handling and IO

2016-04-20 Thread Juergen Sauermann
Hi Elias, that construct is already in place, called an EOC (end-of-context) handler . However, using EOC handlers appears to be easy, but using them properly is extremely difficult, because they require very detailed knowledge of the int

Re: [Bug-apl] Error handling and IO

2016-04-19 Thread Elias Mårtenson
Do you think it would be possible to implement a "finally" construct for native libraries? Basically, what I'm asking for is the ability to register a callback with a specific stack frame that is called when that frame is unrolled. Regards, Elias On 14 Apr 2016 01:51, "Juergen Sauermann" wrote:

Re: [Bug-apl] Error handling and IO

2016-04-13 Thread Juergen Sauermann
Hi Kacper et al, I understand. But I would say that using ⎕EA as you describe is exactly how cleanup should be done. I see ⎕EA not like (as the name may suggest) a means of trying different paths until one succeeds like in: 'try_A' ⎕EA

Re: [Bug-apl] Error handling and IO

2016-04-11 Thread 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 a

Re: [Bug-apl] Error handling and IO

2016-04-11 Thread 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

Re: [Bug-apl] Error handling and IO

2016-04-11 Thread 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, > >

Re: [Bug-apl] Error handling and IO

2016-04-11 Thread 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 o

Re: [Bug-apl] Error handling and IO

2016-04-11 Thread 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

Re: [Bug-apl] Error handling and IO

2016-04-11 Thread 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 functio

Re: [Bug-apl] Error handling and IO

2016-04-10 Thread Elias Mårtenson
Hello Alexey, 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. What is needed is a way to say: "call function X with file handle Y, en

Re: [Bug-apl] Error handling and IO

2016-04-10 Thread Alexey Veretennikov
Hi, In Dyalog APL there is a mechanism similar to try/catch in other languages: R←f X :Trap 0 R←1÷X :Else ⎕←'Error happened' R←0 :EndTrap f 0 Error happened 0 For details see the Mastering Dyalog Apl (http://www.dyalog.com/uploads/documents/MasteringDyalogAPL.pdf) Chapter M: