[Bug-apl] Error handling and IO
Yesterday, I participated in the Google Code Jam (programming competition). For one of the tasks, APL was a very good fit. The question is here: https://code.google.com/codejam/contest/6254486/dashboard#s=p1 My solution (which I will not post right now, since one of you might want to give it a shot first) was terse and simple. A very simple APL expression. However, reading the input a file and formatting the result took many lines of very ugly code. This attempt at using APL to solve a real-world programming problem illustrated two separate issues that, needs to be handled: Firstly, the FILE_IO library is way too low-level. For example, in the Codejam tasks, one usually have to read a whitespace-limited sequence of numbers. When I solve the problems in Lisp, all I need to do is to call READ. A flextible IO probrary that makes these kinds of this simple would be nice. I could (and indeed have considered to) write such functions in APL, but this causes a second problem: Error handling in GNU APL is very bad. In particular, there is nothing similar to UNWIND-PROTECT (or try/finally in Java). There is no way to safely write code that opens a file, works on it and then closes it. If an error occurs, there is no way to ensure that the filehandle is closed. When I developed my solution to the Codejam problem, I ended up leaking a lot of file handles. Does anyone know how Dyalog and other vendors handle this? Do they have a full exception system? Regards, Elias
Re: [Bug-apl] Error handling and IO
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: Event Handling Elias Mårtenson writes: > Yesterday, I participated in the Google Code Jam (programming competition). > For one of the tasks, > APL was a very good fit. The question is here: > https://code.google.com/codejam/contest/6254486/dashboard#s=p1 > > My solution (which I will not post right now, since one of you might want to > give it a shot first) was terse > and simple. A very simple APL expression. > > However, reading the input a file and formatting the result took many lines > of very ugly code. > > This attempt at using APL to solve a real-world programming problem > illustrated two separate issues > that, needs to be handled: > > Firstly, the FILE_IO library is way too low-level. For example, in the > Codejam tasks, one usually have to > read a whitespace-limited sequence of numbers. When I solve the problems in > Lisp, all I need to do is > to call READ. A flextible IO probrary that makes these kinds of this simple > would be nice. > > I could (and indeed have considered to) write such functions in APL, but this > causes a second problem: > > Error handling in GNU APL is very bad. In particular, there is nothing > similar to UNWIND-PROTECT (or > try/finally in Java). There is no way to safely write code that opens a file, > works on it and then closes it. > If an error occurs, there is no way to ensure that the filehandle is closed. > When I developed my solution > to the Codejam problem, I ended up leaking a lot of file handles. > > Does anyone know how Dyalog and other vendors handle this? Do they have a > full exception system? > > Regards, > Elias > -- Br, /Alexey
Re: [Bug-apl] Error handling and IO
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, ensuring that Y is closed after the X has finished, regardless of the way it finishes. Successfully or through an error". I can sort of do with with ⎕EA. I used it in SQL∆WithTransaction, for example. However, if an error occurs anywhere inside the function, all you get is a generic "Transaction rolled back" error, with no indication of what happened or where it happened. This is the functionality that is desperately needed. I'd like to see a more powerful version of ⎕EA that is able to do this. I would also like to hear Jürgens opinions on this first. Regards, Elias On 10 April 2016 at 23:49, Alexey Veretennikov < alexey.veretenni...@gmail.com> wrote: > 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: Event Handling > > > Elias Mårtenson writes: > > > Yesterday, I participated in the Google Code Jam (programming > competition). For one of the tasks, > > APL was a very good fit. The question is here: > > https://code.google.com/codejam/contest/6254486/dashboard#s=p1 > > > > My solution (which I will not post right now, since one of you might > want to give it a shot first) was terse > > and simple. A very simple APL expression. > > > > However, reading the input a file and formatting the result took many > lines of very ugly code. > > > > This attempt at using APL to solve a real-world programming problem > illustrated two separate issues > > that, needs to be handled: > > > > Firstly, the FILE_IO library is way too low-level. For example, in the > Codejam tasks, one usually have to > > read a whitespace-limited sequence of numbers. When I solve the problems > in Lisp, all I need to do is > > to call READ. A flextible IO probrary that makes these kinds of this > simple would be nice. > > > > I could (and indeed have considered to) write such functions in APL, but > this causes a second problem: > > > > Error handling in GNU APL is very bad. In particular, there is nothing > similar to UNWIND-PROTECT (or > > try/finally in Java). There is no way to safely write code that opens a > file, works on it and then closes it. > > If an error occurs, there is no way to ensure that the filehandle is > closed. When I developed my solution > > to the Codejam problem, I ended up leaking a lot of file handles. > > > > Does anyone know how Dyalog and other vendors handle this? Do they have > a full exception system? > > > > Regards, > > Elias > > > > -- > Br, > /Alexey >
